How to use UART3 for bluetooth HCI?

Products Support HiKey 960
#7

Problem is that there is a unpermitted transition from the init domain (init process) to the system_file domain (system file) when executing /system/bin/hciattach. However this should be a transition from init domain to hci_attach domain since you defined /system/bin/hciattach with the hci_attach_exec type (hci_attach domain).
Did you re-flash system and boot partition ?

Not sure, but it could be an android /system/bin restriction, try tor install tools in vendor instead (system/vendor) and add the following rule:
/(vendor|system/vendor)/bin/hciattach u:object_r:hci_attach_exec:s0

In a first step I would suggest to run in permissive mode and run the service manually, then start your service and retrieve all the selinux related errors in dmesg, then fix them manually (if any) or using audit2allow tool.

Once all the rules are fixed you can re-enable enforce mode.

1 Like
#8

Hi Loic,

If I change any sepolicy, usually I re-flash both system and boot. If I change only in init.rc, then only boot.
Moved ‘hciattach’ to /system/vendor, still getting sepolicy denial error -

type=1400 audit(15.555:47): avc: denied { transition } for pid=2159 comm="init" path="/system/vendor/bin/hciattach" dev="sdd10" ino=2539 scontext=u:r:init:s0 tcontext=u:object_r:hci_attach_exec:s0 tclass=process permissive=0

I changed the ‘user’ option to ‘root’ also in the service declaration in init.rc file, still getting the same error. Please help.

Thanking you,

Regards,
Arnab Dey

#9

I think this comes from the seclabel line you added:

Remove it or use this one instead:
seclabel u:r:hci_attach:s0

1 Like
#10

Hi Loic,

If I remove that label, the service is not being called at all as part of init. Using u:r:hci_attach:s0 throws invalid context error.

I used audit2allow tool to analyze and it gave me following suggestion -

allow init hci_attach_exec:process transition;

If I add it in device/linaro/hikey/sepolicy/init.te, and then make system image + boot image again it is not taking effect. Where should I add it? Will I have to clean and rebuild?
Should I add this as suggested by audit2allow ?

Thanking you,

Regards,
Arnab Dey

#11

If you kept the original hikey sepolicy files, domain transition should be already done in hci_attach.te:
init_daemon_domain(hci_attach)

What is looking weird to me is that audit2allow suggest to add the transition rule with hci_attach_exec as destination domaine, this should be hci_attach. So I think there is a problem in your rules, hci_attach is a domain, hci_attach_exec is a type. Could you please check this point and provide all the rules you changed ?

1 Like
#12

Hi Loic,

I have not changed any sepolicy rules. Only I have added the following in device/linaro/hikey/sepolicy/file_contexts -

/(vendor|system/vendor)/bin/hciattach u:object_r:hci_attach_exec:s0

in device/linaro/hikey/ueventd.common.rc, I have modified -

/dev/ttyAMA3      0660 bluetooth bluetooth

My device/linaro/hikey/sepolicy/hci_attach.te contains the following -

type hci_attach, domain;
type hci_attach_exec, exec_type, file_type;

init_daemon_domain(hci_attach)

allow hci_attach kernel:system module_request;
allow hci_attach hci_attach_dev:chr_file rw_file_perms;
allow hci_attach bluetooth_efs_file:dir r_dir_perms;
allow hci_attach bluetooth_efs_file:file r_file_perms;

allow hci_attach rootfs:lnk_file getattr;
allow hci_attach sysfs:file r_file_perms;

Please help.

Thanking you,

Regards,
Arnab Dey

Not able to start my system service added to system_server
#13

Hi Loic,

You are absolutely right. I tried removing ‘seclabel’ and ‘seclabel u:r:hci_attach:s0’ when my hciattach was in /system/bin. After moving it to /system/vendor/bin as suggested by you, I did not try this. Now my hciattach is in system/vendor/bin. I just removed seclabel and it worked fine!!! Thank you a lot!!!
Can you please make me understand why specifying this here causes problem? Is not it equivalent to mentioning in ‘file_contexts’ as we did?

audit2allow shows following suggestions -

#============= audioserver ==============
allow audioserver default_android_service:service_manager add;
allow audioserver hal_broadcastradio_hwservice:hwservice_manager find;

#============= healthd ==============
allow healthd self:capability2 wake_alarm;

#============= init ==============
allow init cgroup:file create;

#============= mediadrmserver ==============
allow mediadrmserver default_android_service:service_manager add;

#============= netd ==============
allow netd proc_net:dir write;

#============= zygote ==============
allow zygote cgroup:file create;

Should I make the suggested changes or skip them?

Thanking you,

Regards,
Arnab Dey

#14

Great !

Not necessarily, except if you observe issues associated.

1 Like
#15

Hi Loic,

Sure. Now, how to make my BT controller to be detected as hci0?

or if I do -

   setprop bluetooth.interface 1

under ‘on post-fs’ will my controller respond from UI(i.e. from android toggle button to turn on/off bluetooth)?

Thanking you,

Regards,
Arnab Dey

#16

The hci ID is allocated by the Bluetooth subsystem (kernel) on hci device creation. So yes you have two possibilities:

  1. Prevent hci0 creation
    Think you can prevent this by removing uim service from init
  2. Force usage of hci1 by the Androdi BT stack
    setprop bluetooth.interface 1 should work, but never tested.
#17

Hi Loic,

removing uim service does not make my BT controller become hci0. Instead default TI chip-hci0 stops responding to bluetooth turning on/off -

service call bluetooth_manager 6

if I have uim running, then the above command turns hci0(TI chip) ‘UP RUNNING’ and without uim there is no effect on hci0(TI chip). It stays ‘DOWN’ in that case.

setprop method also did not work.

Is it possible to change the hikey960 kernel code to achieve this? i.e. I could see in the device tree (/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts) in hikey kernel code,
&uart4 has the following child-node declared -

bluetooth {
compatible = “ti,wl1837-st”;
enable-gpios = <&gpio15 6 GPIO_ACTIVE_HIGH>;
max-speed = <921600>;
};

Is it possible to do some tweaks here for my controller for uart3?
Or is there any specific command I can provide to kernel using ‘BOARD_KERNEL_CMDLINE’ in BoardConfig.mk?

Thanking you,

Regards,
Arnab Dey

#18

OK, so the basic idea would be to remove this bluetooth child node from uart3, then hci0 should not be created.
For your case, don’t add any child node, the ‘enumeration’ performed by user-space (hciattach).

#19

Hi Loic,

Removing child-node from uart4 node did not work. I tried to remove status overlay by making uart4 status=“disabled” in hi3660-hikey960.dts. That also did not work. hci0 was still getting created for TI controller. Can you please guide?

Thanking you,

Regards,
Arnab Dey

#20

I don’t really see how it can work, if you removed uim service and device-tree entry no TI hci device can be created. Could you please double check new DTB is used (build instruction), basically modify your dts, build the new DTB, copy the dtb into aosp /device/linaro/hikey-kernel/hi3660-hikey960.dtb-4.9, and then regenerate and flash the boot image.

Note that you can check access device tree in /proc/device-tree at runtime to check your updates.

1 Like
#21

Hi Loic,

I did exactly what is mentioned in build instruction. I could see the kernel build time and date properly using ‘uname -a’. Still hci0 is getting created for TI controller.

What to check in /proc/device-tree ? following are the contents of this folder -

#address-cells
#size-cells
aliases
apb_pclk
btwilink
chosen
compatible
cpus
ddr_devfreq
dpe@E8600000
dsi@E8601000
fiq-debugger
firmware
hifidsp
hisi,ion
interrupt-controller@e82b0000
interrupt-parent
ipc@e896b000
keys
kim
leds
mali@E82C0000
memory@0
model
name
opp_table0
opp_table1
overlay_mgr
pmic@fff34000
pmu
psci
ramoops
reboot-mode-syscon@32100000
reserved-memory
smmu
smmu_lpae
soc
timer
uart_overlay@0
wlan-en-1-8v

Thanking you,

Regards,
Arnab Dey

#22

You are absolutely right. I just checked the tree nodes under /proc/device-tree/soc/serial@fdf01000 - which is for uart4 and found that bluetooth child-node was not not deleted. That means whatever I changed in ‘hi3660-hikey960.dts’ did not take effect though uname-a shows proper date and time of kernel build. What can be the reason and how can I ensure my changes in the kernel?

Thanking you,

Regards,
Arnab Dey

#23

From kernel dir, you can try make ARCH=arm64 dtbs to regenerate your dtb.

#24

Hi Loic,

Actually the problem was with device tree image(dt.img). As I changed device tree in kernel code, I should rebuild and flash dt.img along with boot.img. In the kernel code(arch/arm64/boot/dts/hisiliconhi3660-hikey960.dts), I just removed bluetooth child node under uart4 and made status=“disabled”. Then rebuilt and flashed both dt.img and boot.img. Now I can see my BT controller as hci0 and it responds to bluetooth service start/stop!!!

However, If I change the kernel code, I do not get any video output from HDMI port. Can you please guide?

Thanking you,

Regards,
Arnab Dey

#25

Yes I missed this point, dt has its own image.

Any related dmesg/logcat output ? (hwcomposer, surfaceflinger, Mali…)

#26

Hi Loic,

Following is an error log related to mali gpu from dmesg -

[32m[ 3.025712] e[0m[drm] Initialized
e[32m[ 3.026446] e[0m[drm] wait for external HDMI bridge driver.
e[32m[ 3.026708] e[33mmali e82c0000.malie[0m: Continuing without Mali regulator control
e[32m[ 3.032634] e[33mmali e82c0000.malie[0m: GPU identified as 0x0 arch 6.0.10 r0p0 status 2
e[32m[ 3.033659] e[33mOFe[31m: ERROR: Bad of_node_put() on /mali@E82C0000
e[32m[ 3.033670] e[33mCPUe[0m: 0 PID: 1 Comm: swapper/0 Tainted: G S 4.9.60-02839-g9ea4cdd-dirty #1
e[32m[ 3.033675] e[33mHardware namee[0m: HiKey960 (DT)
e[32m[ 3.033680] e[0mCall trace:
e[32m[ 3.033696] e[0m[] dump_backtrace+0x0/0x1dc
e[32m[ 3.033703] e[0m[] show_stack+0x20/0x28
e[32m[ 3.033711] e[0m[] dump_stack+0xa8/0xe0
e[32m[ 3.033720] e[0m[] of_node_release+0xa4/0xa8
e[32m[ 3.033726] e[0m[] kobject_put+0x80/0xdc
e[32m[ 3.033731] e[0m[] of_node_put+0x24/0x30
e[32m[ 3.033736] e[0m[] of_find_compatible_node+0xbc/0xe8
e[32m[ 3.033747] e[0m[] kbase_ipa_model_add_param_string+0x68/0x144
e[32m[ 3.033752] e[0m[] kbase_simple_power_model_init+0x130/0x178
e[32m[ 3.033757] e[0m[] kbase_ipa_init_model+0x68/0xf0
e[32m[ 3.033762] e[0m[] kbase_ipa_init+0xa8/0x248
e[32m[ 3.033771] e[0m[] kbase_devfreq_init+0x19c/0x50c
e[32m[ 3.033777] e[0m[] kbase_platform_device_probe+0x604/0xc5c
e[32m[ 3.033785] e[0m[] platform_drv_probe+0x58/0xd0
e[32m[ 3.033791] e[0m[] driver_probe_device+0x224/0x2c4
e[32m[ 3.033796] e[0m[] __driver_attach+0xbc/0xc0
e[32m[ 3.033802] e[0m[] bus_for_each_dev+0x6c/0xac
e[32m[ 3.033807] e[0m[] driver_attach+0x2c/0x34
e[32m[ 3.033812] e[0m[] bus_add_driver+0x1c0/0x224
e[32m[ 3.033817] e[0m[] driver_register+0x7c/0x114
e[32m[ 3.033825] e[0m[] __platform_driver_register+0x60/0x6c
e[32m[ 3.033834] e[0m[] kbase_platform_driver_init+0x18/0x20
e[32m[ 3.033842] e[0m[] do_one_initcall+0x88/0x11c
e[32m[ 3.033847] e[0m[] kernel_init_freeable+0x1c8/0x268
e[32m[ 3.033857] e[0m[] kernel_init+0x20/0x140
e[32m[ 3.033863] e[0m[] ret_from_fork+0x10/0x50
e[32m[ 3.034106] e[33mmali e82c0000.malie[0m: Couldn’t find power_model DT node matching ‘arm,mali-g71-power-model’
e[32m[ 3.034490] e[33mError reading temperature for gpu thermal zonee[0m: -22
e[32m[ 3.039313] e[33mmali e82c0000.malie[0m: Using configured power model mali-g71-power-model, and fallback mali-simple-power-model
e[32m[ 3.044164] e[33mmali e82c0000.malie[0m: Probed as mali0
e[32m[ 3.120216] e[33mbrde[0m: module loaded

Is there any way to attach text file here? I can attach the full dmesg log then.

Thanking you,

Regards,
Arnab Dey