Hi,
I'm part of a community of linux enthusiasts trying to hack the Motorola
E680I phone. Its a based on an Intel PXA270 running MontaVista Linux on
their 2.4.20 kernel. I've been trying to get BlueZ running on it.
The original Bluetooth stack implemented in the firmware is in one
userspace-only app, which talks to ttyS1. So no way to extend
functionality, which badly needs extending. The phone only publishes one
service: Object Push. No way to browse or be browsed, no HID, nothing.
From strace output, it seems to load some kind of firmware into the
phone using a vendor-specific HCI command:
write(3, "\x01\x2e\xfc\x00", 4) = 4
read(3, "\x04\x0e\x04\x01\x2e\xfc\x00", 8) = 7
read(3, "41", 8) = 2
write(3, ":03000000028EB0BD", 17) = 17
read(3, ".", 8) = 1
write(3, ":0B1109008FE18DE2E4F5E375E30122C"..., 33) = 33
.
.
.
Then it programs the Bluetooth address in using another vendor-specific
command (address is 00:12:8a:2d:3d:3e)
write(3, "\x01\x01\xfc\x06\x3e\x3d\x2d\x8a\x12\x00", 10) = 10
read(3, "\x04\x0e\x04\x01\x01\xfc\x00", 8) = 7
I've managed to duplicate this whole process, and get the hci_uart
driver attached to ttyS1. By default when first initialised, the
Bluetooth name is "Broadcom BCM2035".
However, the problem comes when BlueZ requests the Bluetooth address
back from the chip: it will reply with 00:00:00:00:00:00. Seems like its
not a problem unheard of:
http://www.linuxquestions.org/questions/history/341892
l2ping and hcitool scan works despite BlueZ not knowing the correct
local address.
Will this cause any problems BlueZ functionality or other applications?
Is this a sign that the chip is somehow configured wrongly?
Is this a common problem for this chip?
What are the known pitfalls and bugs (besides this one) for BCM2035?
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi,
I just did an interesting experiment:
After the phone's native stack was initialized, I killed off all
processes. Then I did a hciattach to ttyS1, followed by "hciconfig hci0
up". The BD_ADDR still shows 00:00:00:00:00:00.
It seems that the chip can still operate with READ_BD_ADDR returning
00:00:00:00:00:00. The phone's stack though already knows the BD_ADDR
through some other means (which I have not discovered).
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
444 write(14, "\x01\x05\x10\x00", 4) = 4
443 read(14, "\x04", 1) = 1
443 read(14, "\x0e\x0b", 2) = 2
443 read(14, "\x01\x05\x10\x00\x79\x01\x40\x0a\x00\x00\x00", 11) = 11
444 write(14, "\x01\x33\x0c\x07\x1c\x03\x00\x01\x00\x00\x00", 11) = 11
443 read(14, "\x04", 1) = 1
443 read(14, "\x0e\x04", 2) = 2
443 read(14, "\x01\x33\x0c\x00", 4) = 4
444 write(14, "\x01\x09\x0c\x00", 4) = 4
443 read(14, "\x04", 1) = 1
443 read(14, "\x0e\x05", 2) = 2
443 read(14, "\x01\x09\x0c\x00\x00", 5) = 5
444 write(14, "\x01\x20\x0c\x01\x00", 5) = 5
443 read(14, "\x04", 1) = 1
443 read(14, "\x0e\x04", 2) = 2
443 read(14, "\x01\x20\x0c\x00", 4) = 4
444 write(14, "\x01\x22\x0c\x01\x00", 5) = 5
443 read(14, "\x04", 1) = 1
443 read(14, "\x0e\x04", 2) = 2
443 read(14, "\x01\x22\x0c\x00", 4) = 4
444 write(14, "\x01\x26\x0c\x02\x60\x00", 6) = 6
443 read(14, "\x04", 1) = 1
443 read(14, "\x0e\x04", 2) = 2
443 read(14, "\x01\x26\x0c\x00", 4) = 4
443 read(14, <unfinished ...>
444 write(14, "\x01\x13\x0c\xf8\x43\x79\x70\x68\x27\x73\x20\x45\x36\x38\x30\x49\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00", 252) = 252
443 <... read resumed> "\x04", 1) = 1
443 read(14, "\x0e\x04", 2) = 2
443 read(14, "\x01\x13\x0c\x00", 4) = 4
443 read(14, <unfinished ...>
444 write(14, "\x01\x1a\x0c\x01\x02", 5) = 5
443 <... read resumed> "\x04", 1) = 1
443 read(14, "\x0e\x04", 2) = 2
443 read(14, "\x01\x1a\x0c\x00", 4) = 4
443 read(14, <unfinished ...>
444 write(14, "\x01\x24\x0c\x03\x04\x22\x58", 7) = 7
443 <... read resumed> "\x04", 1) = 1
443 read(14, "\x0e\x04", 2) = 2
443 read(14, "\x01\x24\x0c\x00", 4) = 4
443 read(14, <unfinished ...>
Hi,
> I patched the kernel with
> http://www.holtmann.org/linux/kernel/patch-2.4.20-mh18.gz and there is
> test for HCI_QUIRK_RESET_ON_INIT in hci_core.c, although the
> surrounding has changed a bit since then. So all I did was to add the
> flag to hci_ldisc.c, and hcidump verified a reset was issued.
I don't support the 2.4 kernel anymore and I don't have the hardware to
verify if this should work anyhow. I need the test hardware for it or
you need to send a full decoded strace to see what they are doing.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann wrote:
>Hi,
>
>
>
>>>if it is a ROM chip, you may need to call HCI_Reset to establish the new
>>>configuration. For the hci_uart driver you can load it with "reset=1" to
>>>tell the Bluetooth core to always send a reset command first.
>>>
>>>
>>>
>>>
>>I've looked through bluez sources for 2.6.12 and found the "reset"
>>parameter in the hci_uart driver. However, I need to use the MontaVista
>>kernel on this phone. Nevertheless I have modified hci_uart driver to
>>set the appropriate quirks flag, and verified with hcidump that it sent
>>a reset on "hciconfig up". However this still does not work.
>>
>>The phone's native stack though, still works fine. Unlike bluez, it does
>>not read the the BD_ADDR from the chip, which makes sense because it
>>programs the address into the chip...
>>
>>
>
>there exists no backport for the reset quirks for any 2.4 kernels.
>
>
I patched the kernel with
http://www.holtmann.org/linux/kernel/patch-2.4.20-mh18.gz and there is
test for HCI_QUIRK_RESET_ON_INIT in hci_core.c, although the
surrounding has changed a bit since then. So all I did was to add the
flag to hci_ldisc.c, and hcidump verified a reset was issued.
>Regards
>
>Marcel
>
>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by:
>Tame your development challenges with Apache's Geronimo App Server.
>Download it for free - -and be entered to win a 42" plasma tv or your very
>own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
>_______________________________________________
>Bluez-devel mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
>
>
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi,
> >if it is a ROM chip, you may need to call HCI_Reset to establish the new
> >configuration. For the hci_uart driver you can load it with "reset=1" to
> >tell the Bluetooth core to always send a reset command first.
> >
> >
> I've looked through bluez sources for 2.6.12 and found the "reset"
> parameter in the hci_uart driver. However, I need to use the MontaVista
> kernel on this phone. Nevertheless I have modified hci_uart driver to
> set the appropriate quirks flag, and verified with hcidump that it sent
> a reset on "hciconfig up". However this still does not work.
>
> The phone's native stack though, still works fine. Unlike bluez, it does
> not read the the BD_ADDR from the chip, which makes sense because it
> programs the address into the chip...
there exists no backport for the reset quirks for any 2.4 kernels.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann wrote:
>Hi guys,
>
>
>
>>>Is this a sign that the chip is somehow configured wrongly?
>>>
>>>
>>Looks like, but I fear its too late for the the device. Would help a lot if
>>it can take again a valid BD_ADDR. The HCI_USB driver behaves different for
>>this device it casts a reset hci command on it, before the intialitation
>>commands. May there is a point to look at but you are talking over UART...
>>
>>
>
>if it is a ROM chip, you may need to call HCI_Reset to establish the new
>configuration. For the hci_uart driver you can load it with "reset=1" to
>tell the Bluetooth core to always send a reset command first.
>
>
I've looked through bluez sources for 2.6.12 and found the "reset"
parameter in the hci_uart driver. However, I need to use the MontaVista
kernel on this phone. Nevertheless I have modified hci_uart driver to
set the appropriate quirks flag, and verified with hcidump that it sent
a reset on "hciconfig up". However this still does not work.
The phone's native stack though, still works fine. Unlike bluez, it does
not read the the BD_ADDR from the chip, which makes sense because it
programs the address into the chip...
>Regards
>
>Marcel
>
>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by:
>Tame your development challenges with Apache's Geronimo App Server.
>Download it for free - -and be entered to win a 42" plasma tv or your very
>own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
>_______________________________________________
>Bluez-devel mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
>
>
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi guys,
> > Is this a sign that the chip is somehow configured wrongly?
>
> Looks like, but I fear its too late for the the device. Would help a lot if
> it can take again a valid BD_ADDR. The HCI_USB driver behaves different for
> this device it casts a reset hci command on it, before the intialitation
> commands. May there is a point to look at but you are talking over UART...
if it is a ROM chip, you may need to call HCI_Reset to establish the new
configuration. For the hci_uart driver you can load it with "reset=1" to
tell the Bluetooth core to always send a reset command first.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Ho,
> I am thinking more along the lines of "You just told me my BD_ADDR, why
> are you asking for it now?"
I dont understand you as well in here... :P
?? i have not asked
> However, like I said, l2ping works. sdptool also works fine. Perhaps it
> transmits packets with the correct address, just that it would not tell
> BlueZ its BD_ADDR?
I only did research on this problem over the HCI layer, but while the BCM2035
initiates those l2cap/sdp connections, as it is needed the remote BD_ADDR not
ours(phantom one) what you say is possible.
On other hand no other device should be albe to "l2ping" you and in general
connect you. As well as you should not be visible to remote inquiry processes.
> Too late? You mean it will be stuck with this BD_ADDR?
hmmmm I meant, device dead, or with a serious handicap if sounds better as,
it has no BD_ADDR.
thanks,
______________________________________________
Renovamos el Correo Yahoo!
Nuevos servicios, m?s seguridad
http://correo.yahoo.es
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Oliver wrote:
>Ho,
>
> =20
>
>>However, the problem comes when BlueZ requests the Bluetooth address=20
>>back from the chip: it will reply with 00:00:00:00:00:00. Seems like it=
s=20
>>not a problem unheard of:=20
>>http://www.linuxquestions.org/questions/history/341892
>>l2ping and hcitool scan works despite BlueZ not knowing the correct=20
>>local address.
>> =20
>>
>
>It is not a BlueZ problem but a device itself, with the BlueZ stack the=20
>chip uses to forget its BD_ADDR.
> =20
>
I am thinking more along the lines of "You just told me my BD_ADDR, why=20
are you asking for it now?"
> =20
>
>>Will this cause any problems BlueZ functionality or other applications?
>> =20
>>
>
>AFAIK for example another devices could not connect to it, moreover the=20
>fact that a device identifies itself as 00:00:00:00:00:00.
> =20
>
However, like I said, l2ping works. sdptool also works fine. Perhaps it=20
transmits packets with the correct address, just that it would not tell=20
BlueZ its BD_ADDR?
> =20
>
>>Is this a sign that the chip is somehow configured wrongly?
>> =20
>>
>
>Looks like, but I fear its too late for the the device. Would help a lot=
if=20
>it can take again a valid BD_ADDR. The HCI_USB driver behaves different =
for=20
>this device it casts a reset hci command on it, before the intialitation=
=20
>commands. May there is a point to look at but you are talking over UART.=
..
> =20
>
Too late? You mean it will be stuck with this BD_ADDR?
> =20
>
>>Is this a common problem for this chip?
>> =20
>>
>
>I had this problem, I could not make it get its previous BD_ADDR
>
>thanks,
>
> =09
>______________________________________________=20
>Renovamos el Correo Yahoo!=20
>Nuevos servicios, m=E1s seguridad=20
>http://correo.yahoo.es
>
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by:
>Tame your development challenges with Apache's Geronimo App Server.=20
>Download it for free - -and be entered to win a 42" plasma tv or your ve=
ry
>own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.ph=
p
>_______________________________________________
>Bluez-devel mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
> =20
>
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Ho,
> However, the problem comes when BlueZ requests the Bluetooth address
> back from the chip: it will reply with 00:00:00:00:00:00. Seems like its
> not a problem unheard of:
> http://www.linuxquestions.org/questions/history/341892
> l2ping and hcitool scan works despite BlueZ not knowing the correct
> local address.
It is not a BlueZ problem but a device itself, with the BlueZ stack the
chip uses to forget its BD_ADDR.
> Will this cause any problems BlueZ functionality or other applications?
AFAIK for example another devices could not connect to it, moreover the
fact that a device identifies itself as 00:00:00:00:00:00.
> Is this a sign that the chip is somehow configured wrongly?
Looks like, but I fear its too late for the the device. Would help a lot if
it can take again a valid BD_ADDR. The HCI_USB driver behaves different for
this device it casts a reset hci command on it, before the intialitation
commands. May there is a point to look at but you are talking over UART...
> Is this a common problem for this chip?
I had this problem, I could not make it get its previous BD_ADDR
thanks,
______________________________________________
Renovamos el Correo Yahoo!
Nuevos servicios, m?s seguridad
http://correo.yahoo.es
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi,
> >what do think about writing all this stuff up and posting a patch for
> >the hciattach program?
> >
> >
> That will be good, but will take some time. Right now I'm using a
> program totally seperate from hciattach. The only common code is the
> setting of line discipline and HCI protocol. The whole thing is also
> tied together with a shell script that calls a binary program on the
> phone firmware (to load the BCM2035 firmware, set BD_ADDR, and some
> other stuff which have not been figured out.) Meanwhile if anyone is
> interested, the binary is at:
>
> http://cyph.ath.cx:8080/downloads/ezx-bluez-0.2.tar.bz2
>
> Sources are at:
>
> http://cyph.ath.cx:8080/downloads/ezx-bluez-init-0.2.tar.bz2
>
> >I also read that Harald Welte is hacking on the A780 GSM interface. So
> >maybe at some point it is possible to fully replace their binary only
> >stuff.
> >
> >
> That will be good. For some reason, Motorola's linux phone's have not
> attracted as much hacker talent as other devices (e.g. OpenWRT, Ipaq,
> Zaurus). Hopefully it will change. Meanwhile the most active english
> forum seems to be at http://www.motorolafans.com.
try to write some notes about all the specific commands and ioctl stuff
you found. The ultimate goal for most people is to use the 2.6 kernel
series. For Bluetooth this is also important, because we don't support
the 2.4 kernels anymore.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann wrote:
>Hi,
>
>
>
>>Thanks to all those who attempted to help me. Looking through all the
>>code I've hacked together late last night, I spotted a stupid mistake.
>>
>>Long story short, I realised that I was basing my custom hciattach on
>>the wrong set of ioctls. It called a custom ioctle Motorola added to the
>>serial driver that caused the bluetooth chip to reset, therefore falling
>>back to its "default" address.
>>
>>Nevertheless, I hope this exercise can let some of you know about the
>>vendor-specific HCI commands that can be used to program the BCM2035,
>>especially programming in a custom BD_ADDR.
>>
>>
>
>what do think about writing all this stuff up and posting a patch for
>the hciattach program?
>
>
That will be good, but will take some time. Right now I'm using a
program totally seperate from hciattach. The only common code is the
setting of line discipline and HCI protocol. The whole thing is also
tied together with a shell script that calls a binary program on the
phone firmware (to load the BCM2035 firmware, set BD_ADDR, and some
other stuff which have not been figured out.) Meanwhile if anyone is
interested, the binary is at:
http://cyph.ath.cx:8080/downloads/ezx-bluez-0.2.tar.bz2
Sources are at:
http://cyph.ath.cx:8080/downloads/ezx-bluez-init-0.2.tar.bz2
>I also read that Harald Welte is hacking on the A780 GSM interface. So
>maybe at some point it is possible to fully replace their binary only
>stuff.
>
>
That will be good. For some reason, Motorola's linux phone's have not
attracted as much hacker talent as other devices (e.g. OpenWRT, Ipaq,
Zaurus). Hopefully it will change. Meanwhile the most active english
forum seems to be at http://www.motorolafans.com.
>Regards
>
>Marcel
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Power Architecture Resource Center: Free content, downloads, discussions,
>and more. http://solutions.newsforge.com/ibmarch.tmpl
>_______________________________________________
>Bluez-devel mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
>
>
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi,
> Thanks to all those who attempted to help me. Looking through all the
> code I've hacked together late last night, I spotted a stupid mistake.
>
> Long story short, I realised that I was basing my custom hciattach on
> the wrong set of ioctls. It called a custom ioctle Motorola added to the
> serial driver that caused the bluetooth chip to reset, therefore falling
> back to its "default" address.
>
> Nevertheless, I hope this exercise can let some of you know about the
> vendor-specific HCI commands that can be used to program the BCM2035,
> especially programming in a custom BD_ADDR.
what do think about writing all this stuff up and posting a patch for
the hciattach program?
I also read that Harald Welte is hacking on the A780 GSM interface. So
maybe at some point it is possible to fully replace their binary only
stuff.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi,
Thanks to all those who attempted to help me. Looking through all the
code I've hacked together late last night, I spotted a stupid mistake.
Long story short, I realised that I was basing my custom hciattach on
the wrong set of ioctls. It called a custom ioctle Motorola added to the
serial driver that caused the bluetooth chip to reset, therefore falling
back to its "default" address.
Nevertheless, I hope this exercise can let some of you know about the
vendor-specific HCI commands that can be used to program the BCM2035,
especially programming in a custom BD_ADDR.
Thanks again!
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel