Anyone got any ideas or have we given up on this? Cheers. On Tue, May 17, 2011 at 1:45 PM, Eponymous - <the.epon@xxxxxxxxx> wrote: > lsusb: > > Bus 001 Device 041: ID 0a12:0001 Cambridge Silicon Radio, Ltd > Bluetooth Dongle (HCI mode) > Bus 001 Device 040: ID 0a12:0001 Cambridge Silicon Radio, Ltd > Bluetooth Dongle (HCI mode) > > These are definitely plain USB devices. There is no /dev/ttyUSBxx like > you would get with the FTDI USB->Serial converters. > > I've checked over dmesg and the messages (of which there are many > since I have eight of these devices) says they are USB. > > I don't want to become sidetracked from the issue though. Is there > anyway to debug this issue without using l2test or any other > upperlayers program? The issue I have seen was at the HCI level > remember so I'm thinking introducing the upperlayers is going to make > things unnecessarily complicated. > > Cheers. > > > On Tue, May 17, 2011 at 12:50 PM, Anderson Lizardo > <anderson.lizardo@xxxxxxxxxxxxx> wrote: >> Hi, >> >> On Tue, May 17, 2011 at 3:13 AM, Eponymous - <the.epon@xxxxxxxxx> wrote: >>> The chips are CSR Bluecores. In order to get upperlayers access rather >>> than HCI over USB you have to configure a key in the firmware. >>> >>> As soon as I enable upperlayers access the devices disappear from hciconfig. >> >> As I said, there are various development/prototype devices out there >> that use UART (usually CDC ACM or FTDI over USB) transport instead of >> "plain" USB. If you post the relevant lines from "dmesg" and "lsusb" >> somewhere (after you configure the firmware key), we might be able to >> identify the transport. >> >> For UART, you need to use hciattach on a e.g. /dev/ttyUSBX device >> created when plugging the device. >> >> HTH, >> -- >> Anderson Lizardo >> Instituto Nokia de Tecnologia - INdT >> Manaus - Brazil >> > -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
