x

x

Hi,

As Sinoj mentioned, AM3517 is not supported by the current Drivers.

However, we are working on enabling this support shortly, please stay tuned.

Regards,

Adann

HI

I used the AM35x-OMAP35x-PSP-SDK-03.00.00.05 patces WILink 6 on AM3517 EVM

I reference this document "1016614A_AM3517_EVM_WiLink_6-0_Getting_Started_Guide"  to  enable bluetooth

But i execute hciattach tool to enable bluetooth will fail , why?

root@am3517-evm:~# dbus-uuidgen --ensure
root@am3517-evm:~# grep messagebus /etc/passwd
messagebus:sXKqf3qGOIUHg:500:500:Linux User,,,:/home/messagebus:/bin/sh
root@am3517-evm:~# adduser messagebus
adduser: messagebus: login already in use
root@am3517-evm:~# mkdir /var/run/dbus
root@am3517-evm:~# dbus-daemon --system --fork
root@am3517-evm:~# bluetoothd
root@am3517-evm:~# echo 0 > /sys/class/gpio/gpio56/value
root@am3517-evm:~# sleep 1
root@am3517-evm:~# echo 1 > /sys/class/gpio/gpio56/value
root@am3517-evm:~# hciattach -t 50 /dev/ttyS1 texas 115200
Found a Texas Instruments' chip!
Firmware file : /lib/firmware/TIInit_7.2.31.bts
Loaded BTS script version 1
texas: changing baud rate to 3000000, flow control to 1
ll_recv: Unknown HCI packet type ff
Cannot send hci command to socket: Network is down
Can't initialize device: Network is down

root@am3517-evm:~# hciconfig hci0 -a
Can't get device info: No such device

Thanks

Nathan.kuo

Hi Nathan.kuo,

Can you please provide the version information or download link to the software release for AM3517 -Wl1271?

However, i could see one problem in the log. Hciattach command used is  " hciattach -t 50 /dev/ttyS1 texas 115200"

So, you got the chip version an changed the baud rate to 3000000. It seems the bts file was for 3M baud. However the hciattach baud parameter was 115200

Can you please try this "hciattach -t 50 /dev/ttyS1 texas 3000000"?

Thanks,

Sinoj

I'm also using am3517 based board and have the same problems. Kernel 2.6.37 from http://arago-project.org/git/projects/?p=linux-omap3.git;a=summary and bluez 4.96. How can I persuade hciattach not to increase the baudrate? As far as I understand these settings come from tbs file?

# hciattach /dev/ttyO1 texas 115200
Found a Texas Instruments' chip!
Firmware file : /lib/firmware/TIInit_7.2.31.bts
Loaded BTS script version 1
texas: changing baud rate to 3000000, flow control to 1
ll_recv: Unknown HCI packet type ff
Initialization timed out.

rfc2217,

       Unfortunately, the default configuration is set to 3Mbps only inside the BTS file.

Regards,

~Miguel

Miguel,

now I think 3Mbps is not a problem, cause after changing speed I still can send and receive hcill packets. if I compile bluez with debugging output I get following:

Found a Texas Instruments' chip!
Firmware file : /lib/firmware/TIInit_7.2.31.bts
Sending script to serial device
Loaded BTS script version 1
texas: changing baud rate to 3000000, flow control to 1
ll_recv: Unknown HCI packet type ff
CCCCCCCCWRCSCCCCCCCCCCCCCCCCWRCWRWRWRWRWRWRCWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWCRCCWRCCCCCWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRCWRWRWRWRWRWRWRWRWRWRCCCCCCCCWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRCCWRWRCCCCCCCCCCCCCCCCCCCCCCC
Added device hci1
Initialization timed out.

The massage "ll_recv: Unknown HCI packet type ff" comes from kernel hci_ll driver. There is such packet as HCI_VENDOR_PKT, but it won't be handled, so driver thinks it is an error. Could you provide a dump of all hci packets during initialization, so I can compare it with mine. I'm using BT firmware from linux-firmware repo.

Regards,

rfc2217

I enabled BT_DBG in kernel and that is my output:

hci_uart_tty_ioctl:
ll_open: hu ce1ffe40
hci_uart_register_dev:
hci_register_dev: ce10d000 name  bus 3 owner   (null)
hci_register_sysfs: ce10d000 name hci0 bus 3
hci_sock_dev_event: hdev hci0 event 1
hci_send_to_sock: hdev   (null) len 8
l2cap_sock_create: sock ce7594c0
l2cap_sock_init: sk ce376800
l2cap_sock_bind: sk ce376800
l2cap_sock_listen: sk ce376800 backlog 5
bnep_sock_create: sock ce759940
sco_sock_create: sock ca820dc0
sco_sock_init: sk ce362800
sco_sock_bind: sk ce362800 00:00:00:00:00:00
sco_sock_listen: sk ce362800 backlog 5
hci_sock_create: sock ca820b80
hci_sock_bind: sock ca820b80 sk ce389c00
hci_sock_sendmsg: sock ca820b80 sk ce389c00
hci_sock_release: sock ca820b80 sk ce389c00
hci_sock_create: sock ca820b80
hci_sock_setsockopt: sk ce389c00, opt 2
hci_sock_bind: sock ca820b80 sk ce389c00
bt_sock_poll: sock ce7594c0, sk ce376800
bt_sock_poll: sock ca820dc0, sk ce362800
bt_sock_poll: sock ce7594c0, sk ce376800
bt_sock_poll: sock ca820dc0, sk ce362800
hci_sock_ioctl: cmd 800448d2 arg 40429ef0
hci_sock_create: sock ca820940
hci_sock_bind: sock ca820940 sk ce389800
hci_dev_get: 0
hci_sock_setsockopt: sk ce389800, opt 2
bt_sock_poll: sock ce7594c0, sk ce376800
bt_sock_poll: sock ca820dc0, sk ce362800
hci_sock_ioctl: cmd 400448e2 arg be9e0af0
hci_dev_get: 0
hci_sock_ioctl: cmd 400448c9 arg 0
hci_dev_get: 0
hci_dev_open: hci0 ce10d000
hci_uart_open: hci0 ce10d000
__hci_request: hci0 start
hci_init_req: hci0 0
hci_send_cmd: hci0 opcode 0x1003 plen 0
hci_send_cmd: skb len 3
hci_send_cmd: hci0 opcode 0x1001 plen 0
hci_send_cmd: skb len 3
hci_send_cmd: hci0 opcode 0x1005 plen 0
hci_cmd_task: hci0 cmd 1
hci_send_frame: hci0 type 1 len 3
hci_send_to_sock: hdev ce10d000 len 3
hci_uart_send_frame: hci0: type 1 len 3
ll_enqueue: hu ce1ffe40 skb ce145bc0
ll_enqueue: device awake, sending normally
hci_uart_tx_wakeup:
hci_uart_tty_wakeup:
hci_uart_tx_wakeup:
hci_send_cmd: skb len 3
hci_send_cmd: hci0 opcode 0x1009 plen 0
hci_send_cmd: skb len 3
hci_send_cmd: hci0 opcode 0xc23 plen 0
hci_cmd_task: hci0 cmd 0
hci_send_cmd: skb len 3
hci_send_cmd: hci0 opcode 0xc14 plen 0
hci_send_cmd: skb len 3
hci_send_cmd: hci0 opcode 0xc25 plen 0
hci_cmd_task: hci0 cmd 0
hci_send_cmd: skb len 3
hci_send_cmd: hci0 opcode 0xc05 plen 1
hci_cmd_task: hci0 cmd 0
hci_send_cmd: skb len 4
hci_send_cmd: hci0 opcode 0xc18 plen 2
hci_cmd_task: hci0 cmd 0
hci_send_cmd: skb len 5
hci_send_cmd: hci0 opcode 0xc16 plen 2
hci_send_cmd: skb len 5
hci_cmd_task: hci0 cmd 0
ll_recv: hu ce1ffe40 count 1 rx_state 0 rx_count 0
ll_recv: Unknown HCI packet type ff
hci_uart_tty_ioctl:
hci_sock_create: sock ca820700
hci_sock_bind: sock ca820700 sk ce389400
hci_dev_get: 0
hci_sock_ioctl: cmd 400448c9 arg 0
hci_dev_get: 0
hci_dev_open: hci0 ce10d000

'ff' seems to be the first received packet. What should the proper first packet?

I've got the stuff working!!! The problem was a wrong baudrate settings. The proper parameters are:

hciattach -s 115200 /dev/ttyO1 texas 3000000

Background: hciattach uses own baudrate settings "-s initial_speed" for initial speed and "speed". Specifying only one of them results in assigning the same value to both speeds. Though baudrate change is described in the firmware and one can see that the baudrate will be changed to 3000000, in the next step hciattach will set the speed according to "speed" value, so the value in script is overridden. That's why one needs to specify both of them.

In the output below you can see that baudrate 3Mb/s will be set 2 times:

#hciattach -s 115200 /dev/ttyO1 texas 3000000
DBG: set speed 115200
Found a Texas Instruments' chip!
Firmware file : /lib/firmware/TIInit_7.2.31.bts
Loaded BTS script version 1
texas: changing baud rate to 3000000, flow control to 1
DBG: set speed 3000000
DBG: set speed 3000000
Device setup complete

My system:

SoC: am3517

Kernel: 2.6.37 (arago git repo)

BlueZ: 4.96

OS: Buildroot 2011.08-rc2

Hi

I am also looking into bluetooth driver, I want  enable BT_DBG to understand complete flow.

I am using kernel-3.5 and it is configured bluetooth subsystem,bluetooth driver and TI wilink driver selected as  part of kernel(* option).

Is it possible to enable BT_DBG flag to print driver debug prints???

Thanks

ram

Hi,

I hope you are talking about the BT_DBG log function, I don't see any problem in defining the BT_DBG.

I think you do somthing like below

#define BT_DBG(fmt, ...)    pr_info(fmt "%s\n", ##__VA_ARGS__, __function__)