09-22-2015 02:20 PM
6,009 ... 217218219220221 ...
tools
  1. Dannemand's Avatar
    @Schlidel: Since this problem exists in multiple ROMs for different phones, I would speculate there is a module in CM that needs to be adapted for each phone in order to properly pick up the Bluetooth MAC address. In that case it would be a common CM issue, but one that can only be fixed in a hardware specific implementation. Since CM doesn't officially support our phones, they may not consider it their problem.

    That bdaddr_read module I mention in the IHO repository, gets the address from a Broadcom service (which I think is generic). Maybe that service returns the wrong address - or maybe bdaddr_read doesn't save the address properly for the Bluetooth daemon to pick up.

    I honestly shouldn't post these speculations here. I am sure the devs are laughing or rolling their eyes over my ignorance :o
    Schlidel and glarepate like this.
    05-14-2012 04:36 PM
  2. mrg666's Avatar
    @Schlidel: Since this problem exists in multiple ROMs for different phones, I would speculate there is a module in CM that needs to be adapted for each phone in order to properly pick up the Bluetooth MAC address. In that case it would be a common CM issue, but one that can only be fixed in a hardware specific implementation. Since CM doesn't officially support our phones, they may not consider it their problem.

    That bdaddr_read module I mention in the IHO repository, gets the address from a Broadcom service (which I think is generic). Maybe that service returns the wrong address - or maybe bdaddr_read doesn't save the address properly for the Bluetooth daemon to pick up.

    I honestly shouldn't post these speculations here. I am sure the devs are laughing or rolling their eyes over my ignorance :o
    I am definitely not rolling my eyes. I will look into this bluetooth address issue. Let me see what can I do.
    05-15-2012 04:04 PM
  3. mrg666's Avatar
    I have uploaded the 05152012 build of MiRaGe to the IHO Wiki.
    Followings are the main changes from CM repo sync. You can find details of the changes in CM repo at this link.
    - Remove misleading "default" indication in CMParts
    - Make compcache script fail-safe
    - Make absolutely sure the theme change receivers are only unregistered if
    they were registered before.
    - Optimize T9Search performance / memory consumption
    - Busybox 1.20.0 squashed commit for gingerbread and fixes after that
    - RC2

    I have also updated the data indicators in the status bar (made myself). The bluetooth indicator icon was plain ugly and 3G/1X indicators had always the arrows in wrong directions. Nobody noticed since the up/down arrows were so tiny that the direction they point was not easy to see.

    The same ROM modified for Verizon Network is also available here. MD5sum: 9a697d6bfdba8547e48b655aa792eefc

    As always thanks to Blarf, Bob, Jerry, LeslieAnn, tdm, thekraven, gannon5197, tvall, bigsupersquid, Whyzor, Earthnfire78, and all of the CM team.
    05-15-2012 04:14 PM
  4. Schlidel's Avatar
    I am definitely not rolling my eyes. I will look into this bluetooth address issue. Let me see what can I do.
    Oh heaven's yes.

    Sent from my VM670 using Android Central Forums
    05-15-2012 04:15 PM
  5. mrg666's Avatar
    Oh heaven's yes.

    Sent from my VM670 using Android Central Forums
    I have tried the Hdyro kernel first to check the 2.6.35 GB kernel. It gives the same bluetooth MAC address as IHO kernel. So LG's 2.6.35 official GB kernel cannot help us. On the other hand, this is certainly not a CM7 problem since the other device that I also build CM7, Nook Color, does not have this problem. The two devices have different BT chips and I think OV's problem lies within the Broadcom driver. I think so because the BCM4325 driver in Hydrokernel is the same version with IHO kernel (there are slight changes in the driver code due to different header files in two kernels). I will try to find an updated BCM4325 driver. If not we will need to fix the BCM4325 driver. Please comment if I am missing something.
    05-15-2012 06:56 PM
  6. Dannemand's Avatar
    @mrg666: You're awesome, thanks a lot. Both for your work and for being so nice about it. Seriously!

    One question: Were you able to determine that it actually is the Broadcom service returning the wrong address - and not just bdaddr_read (which I believe WAS localized for IHO) that saves it incorrectly (or in a way so that dependent processes never pick it up right)?

    Is there a way to call that Broadcom service straight and display (or log) the address it returns?

    Just a thought, so you don't spend time replacing or fixing the Broadcom driver, only to find that it was a simple mistake in bdaddr_read.

    Again, sorry if I am confusing things...
    mrg666 and Schlidel like this.
    05-15-2012 08:04 PM
  7. mrg666's Avatar
    @mrg666: You're awesome, thanks a lot. Both for your work and for being so nice about it. Seriously!

    One question: Were you able to determine that it actually is the Broadcom service returning the wrong address - and not just bdaddr_read (which I believe WAS localized for IHO) that saves it incorrectly (or in a way so that dependent processes never pick it up right)?

    Is there a way to call that Broadcom service straight and display (or log) the address it returns?

    Just a thought, so you don't spend time replacing or fixing the Broadcom driver, only to find that it was a simple mistake in bdaddr_read.

    Again, sorry if I am confusing things...
    CM7/IHO seems to read the bluetooth address from /sys/devices/virtual/bluetooth/hci0/address. Guess what is inside that file? 43:251:00:00:00. So Android has no problem reading it. The bcm4325 driver in the Linux kernel writes the wrong information in sysfs. We need to fix the driver. Let's see how can we do that.

    Edit: the sys file is there only when the bluetooth is on. From dmesg, the function that turns on the blueooth is thunderc_bluetooth_power which is in arch/arm/mach-msm/lge/board-thunderc-bt.c in the kernel source. Now we need to trace back from here which function assigns the MAC address and writes that file.
    Schlidel, Dannemand and jayleekay like this.
    05-15-2012 08:17 PM
  8. Dannemand's Avatar
    @mrg: isn't that a completely virtual file? As in, generated on the fly whenever opened. I thought that was how much of the stuff in sysfs is exposed. If so, it may not be written by anybody.

    Yeah, I noticed too when trying to mess with it that the entire /sys/devices/virtual/bluetooth folder only comes into existence when BT is enabled.

    One question: Since this problem is nonexistent in stock ROM, clearly the LG Broadcom driver in the stock kernel must be working. Either we're not using that driver in IHO kernel OR parts of the ROM (CM7 or IHO) is not calling it correctly. Yes, no?
    05-15-2012 11:44 PM
  9. EarthnFire78's Avatar
    Drives work by reading hardware type and generates files as to what the drivers_read_head kicks back, if there is a problem with the driver or a simple typo then the wrong data will be output.

    Gamers would remember how the drivers ATI used for their video cards had typos because Microsoft did not release the source code for Windows Vista to ATI, and caused a great videos card to not functions right.
    Dannemand likes this.
    05-16-2012 12:14 AM
  10. Eollie's Avatar
    Dane I pm'ed mgr this, I googled the problem and the epic 4g has a bug report up about it. I also seen several other results for various phones. I think that is why he is making the connection. Nothing has been posted as a fix that I seen. But it also could have been forgotten about like it was here.

    The only port of CM7 for my new phone is a pain in the *** to flash plus it reminds me of asopbots build of cm7. To many broken things.
    Dannemand likes this.
    05-16-2012 01:45 AM
  11. Dannemand's Avatar
    Dane I pm'ed mgr this, I googled the problem and the epic 4g has a bug report up about it. I also seen several other results for various phones. I think that is why he is making the connection. Nothing has been posted as a fix that I seen. But it also could have been forgotten about like it was here.

    The only port of CM7 for my new phone is a pain in the *** to flash plus it reminds me of asopbots build of cm7. To many broken things.
    Thanks Eollie. Yes, before I made my lengthy post this weekend, I did a lot of searching, and I found too that users of several different CM7 ROMs (and even CM9) had this problem -- but not all. That's why I tentatively concluded that it had to be something in CM7 that must be adapted for each hardware type in order to work (ie drivers). As mrg says, it works fine on his Nook. But on various other devices (including our OVs) it doesn't.

    The fact that it works on stock ROM leaves me wondering if (once again) the combination of our IHO-modified Froyo kernel with CM7 Gingerbread is where the disconnect happens. But then, I tried tdm's Gingerkernel as well -- and it has the same problem...
    Schlidel likes this.
    05-16-2012 10:44 AM
  12. Dannemand's Avatar
    Drives work by reading hardware type and generates files as to what the drivers_read_head kicks back, if there is a problem with the driver or a simple typo then the wrong data will be output.
    Thank you EarthnFire. Yeah I know how drivers work in general (having written many myself). My question to mrg was whether the address file was truly a written and saved file (in which case we want to find who wrote it) or merely a virtual file triggering a read of the hardware MAC address (in which case we need to fix or replace the driver that obviously doesn't read it right).

    I don't know enough about sysfs (it came long after my heydays :o )
    Schlidel likes this.
    05-16-2012 10:53 AM
  13. mrg666's Avatar
    Thank you EarthnFire. Yeah I know how drivers work in general (having written many myself). My question to mrg was whether the address file was truly a written and saved file (in which case we want to find who wrote it) or merely a virtual file triggering a read of the hardware MAC address (in which case we need to fix or replace the driver that obviously doesn't read it right).

    I don't know enough about sysfs (it came long after my heydays :o )
    I have checked the script init.thunderc.rc in IHO calling /bin/hciattach where the firmware /bin/BCM4325.hcd is loaded and bluetooth initialized. But I did not see any problems. I have also tried BCM4325.hcd in LG's Optimus S Gingerbread update which was different than what we have in IHO. It worked but didn't make any difference regarding the MAC address. Two possibilities remain, either we are missing something in the initialization of bluetooth on the IHO side or the bluetooth driver in the kernel is not setting the bdaddr properly. From what I see, I can only conclude that the CM7 part is working fine.
    Schlidel, kraven, tvall and 1 others like this.
    05-16-2012 12:20 PM
  14. faheyd's Avatar
    I have checked the script init.thunderc.rc in IHO calling /bin/hciattach where the firmware /bin/BCM4325.hcd is loaded and bluetooth initialized. But I did not see any problems. I have also tried BCM4325.hcd in LG's Optimus S Gingerbread update which was different than what we have in IHO. It worked but didn't make any difference regarding the MAC address. Two possibilities remain, either we are missing something in the initialization of bluetooth on the IHO side or the bluetooth driver in the kernel is not setting the bdaddr properly. From what I see, I can only conclude that the CM7 part is working fine.
    Go ahead and slap me if this is totally off base since I'm not a sysdev.
    You have a working NOOK and a Non-Working Optimus.
    Put both device drivers in debug mode and grep for the bluetooth stuff. That should clue you in, on where in the code the bluetooth addy's are being done.

    /stop_slapping_me
    Dylan
    Schlidel likes this.
    05-16-2012 02:27 PM
  15. mrg666's Avatar
    Good news! I think I have fixed the bluetooth MAC problem. Problem was with the IHO configuration. First, there is a missing property in /system/build.prop. The following property need to be set with the mac address you want to use (12 character long string, just replace the XXXXXX part as you wish in hexadecimal digits).

    service.brcm.bt.mac=4321D1XXXXXX

    bdaddr_read invoked in init.thunderc.rc during boot takes this value and writes into /data/bdaddr as a MAC address and also sets another system property as
    ro.bt.bdaddr_path=/data/bdaddr

    Second problem is with /system/bin/brcm_patchram_plus which actually is supposed to set the MAC address of the bluetooth interface reading from the filename set in ro.bt.addr_path. This is also run during boot from init.thunderc.rc. The source code of brcm_patchram_plus.c has a bug in the IHO repo. It tries to read from /sys/module/board_htcraphael_rfkill/parameters/bdaddr and disregards the system property ro.bt.addr_path. I have found the fixed code and recompiled.

    After modifying build.prop and fixing brcm_patchram_plus, the bluetooth MAC is properly set on my phone in the next boot. Let me test this a little more and I will post the final changes here. If you want to play with these, I have attached a fixed binary of brcm_patchram_plus here. Just replace the original file in /system/bin with this one and edit your build.prop with your MAC choice. It would be good if you post your feedback if you try.

    [HL]EDIT: see the following post for the updates[/HL]
    http://forums.androidcentral.com/sea...duser&u=410776
    05-16-2012 04:51 PM
  16. Schlidel's Avatar
    This is great news!

    Where in build.prop should I add that line?

    I tried adding it to the end and once somewhere else, but my address didnt change either time after reboot.

    I replaced patchram file also before editing build.prop.

    This could very easily be my fault.

    Edit: This is the line I added. Is it valid? service.brcm.bt.mac=4321D1765432

    Sent from my LG-VM670 using Android Central Forums
    mrg666 likes this.
    05-16-2012 05:23 PM
  17. mrg666's Avatar
    This is great news!

    Where in build.prop should I add that line?

    I tried adding it to the end and once somewhere else, but my address didnt change either time after reboot.

    I replaced patchram file also before editing build.prop.

    This could very easily be my fault.

    Sent from my LG-VM670 using Android Central Forums
    I added as follows

    Code:
    # end build properties
    #
    # system.prop for thunderc
    #
    service.brcm.bt.mac=4321D1122334
    persist.mvpdm.ProxyServerAddr=68.28.31.1
    persist.mvpdm.ProxyServerIp=80
    ro.lge.proximity.delay=100
    ro.ril.def.preferred.network=4
    ro.telephony.default_network=4
    When you replace the binary in /system/bin, don't forget to make it executable again.

    I have confirmed on a second phone. Above method works. Don't forget rebooting.
    Schlidel, Dolok and Dannemand like this.
    05-16-2012 05:26 PM
  18. Schlidel's Avatar
    Yes! It works!

    I had to make patchram executable, thanks.

    You are incredible.

    Sent from my LG-VM670 using Android Central Forums
    mrg666 likes this.
    05-16-2012 05:36 PM
  19. EarthnFire78's Avatar
    Good news! I think I have fixed the bluetooth MAC problem. Problem was with the IHO configuration. First, there is a missing property in /system/build.prop. The following property need to be set with the mac address you want to use (12 character long string, just replace the XXXXXX part as you wish in hexadecimal digits).

    service.brcm.bt.mac=4321D1XXXXXX

    bdaddr_read invoked in init.thunderc.rc during boot takes this value and writes into /data/bdaddr as a MAC address and also sets another system property as
    ro.bt.bdaddr_path=/data/bdaddr

    Second problem is with /system/bin/brcm_patchram_plus which actually is supposed to set the MAC address of the bluetooth interface reading from the filename set in ro.bt.addr_path. This is also run during boot from init.thunderc.rc. The source code of brcm_patchram_plus.c has a bug in the IHO repo. It tries to read from /sys/module/board_htcraphael_rfkill/parameters/bdaddr and disregards the system property ro.bt.addr_path. I have found the fixed code and recompiled.

    After modifying build.prop and fixing brcm_patchram_plus, the bluetooth MAC is properly set on my phone in the next boot. Let me test this a little more and I will post the final changes here. If you want to play with these, I have attached a fixed binary of brcm_patchram_plus here. Just replace the original file in /system/bin with this one and edit your build.prop with your MAC choice. It would be good if you post your feedback if you try.
    So if I repo the fixed code in replace the the bluetooth folder with the newly repoed one, that well compile the bluetooth address fix?

    I was looking all over the kernel source and could not find anything wrong with it, glad you found the fix.
    05-16-2012 05:41 PM
  20. mrg666's Avatar
    Yes! It works!

    I had to make patchram executable, thanks.

    You are incredible.

    Sent from my LG-VM670 using Android Central Forums
    Now that we can change the BT MAC address, the next problem is again the same. If I set a MAC number in build.prop and release the ROM, all of the phones will have the same value again. The user can change this now but it is not an elegant solution. I am looking into giving each phone a different MAC address and keep it persistent between the ROM updates. Well, I can't help with a clean wipe though
    05-16-2012 05:45 PM
  21. Schlidel's Avatar
    Now that we can change the BT MAC address, the next problem is again the same. If I set a MAC number in build.prop and release the ROM, all of the phones will have the same value again. The user can change this now but it is not an elegant solution. I am looking into giving each phone a different MAC address and keep it persistent between the ROM updates. Well, I can't help with a clean wipe though
    Ah yes, I see it its tricky to have it randomized yet persistent between updates. (I think this is what you mean)

    I wish I could help, but it sounds like it would take me years of experience first.

    I really appreciate your work. This has me so pumped/stoked/excited.

    Sent from my LG-VM670 using Android Central Forums
    05-16-2012 05:57 PM
  22. Tejer's Avatar
    Now that we can change the BT MAC address, the next problem is again the same. If I set a MAC number in build.prop and release the ROM, all of the phones will have the same value again. The user can change this now but it is not an elegant solution. I am looking into giving each phone a different MAC address and keep it persistent between the ROM updates. Well, I can't help with a clean wipe though
    Not to sound like the noob I am with this kind of thing, but would it be feasible to just add a setting option under wireless and networks / Bluetooth that would allow users to change it on their own, otherwise having a default address that all phones could share?
    05-16-2012 06:00 PM
  23. EarthnFire78's Avatar
    Now that we can change the BT MAC address, the next problem is again the same. If I set a MAC number in build.prop and release the ROM, all of the phones will have the same value again. The user can change this now but it is not an elegant solution. I am looking into giving each phone a different MAC address and keep it persistent between the ROM updates. Well, I can't help with a clean wipe though
    How about a script that writes to the build.prop on first boot that assigns a mac based on date and time, and then after it's ran it can be removed or renamed .bak.
    05-16-2012 06:08 PM
  24. mrg666's Avatar
    Not to sound like the noob I am with this kind of thing, but would it be feasible to just add a setting option under wireless and networks / Bluetooth that would allow users to change it on their own, otherwise having a default address that all phones could share?
    Thanks for the suggestion. But I don't think adding a setting to the already crowded options is a good idea. The MAC is just a number that needs to be valid and different.
    How about a script that writes to the build.prop on first boot that assigns a mac based on date and time, and then after it's ran it can be removed or renamed .bak.
    Something like that. The following single line does the job.
    Code:
    printf '4321D1%02X%02X%02X\n' $[RANDOM%256] $[RANDOM%256] $[RANDOM%256]
    Now how to insert into boot process?

    The problem is init.thunderc.rc executes after build.prop is processed. init.rc needs to be modified which I don't want.
    05-16-2012 06:10 PM
  25. Dannemand's Avatar
    Just joined now and saw the great news. That's amazing mrg, it really is. I'm gonna see if I can get to try it tonight. Otherwise maybe only tomorrow.

    I presume what stock ROM does is read a unique MAC stored deep in EEPROM (yeah, I know, it's flash nowadays ) where it's accessible by the Broadcom driver, and that way it survives wipes and ROM updates. Being able to read that unique MAC is ideal, of course.

    If it has to be stored in the ROM or data, I would prefer to have an editable option in settings as suggested by Tejer. The problem with randomizing it based on date & time is you'll have to re-pair with your car(s), headsets etc all the time. Of course if it's in data, it'll only be on clean installs.

    Anyways thanks a lot. You did it again, man. That's incredible

    Edit: On second thought, I think a combination of the randomized MAC and an easily accesible setting is the best solution: The randomized MAC on first boot will get the user going with a unique Bluetooth address. The user then notes down his uniqe MAC and can enter it again manually after a wipe -- much easier than pairing a bunch of devices again because the MAC was re-randomized.
    mrg666 likes this.
    05-16-2012 07:08 PM
6,009 ... 217218219220221 ...
LINK TO POST COPIED TO CLIPBOARD