[ROM+Kernel] Inferior Human Organs unofficial CM7.1

[Dannemand]

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 ass 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...

 

[Dannemand]

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 )

 

[mrg666]

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 )

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.

 

[faheyd]

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

 

[mrg666]

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.

EDIT: see the following post for the updates
http://forums.androidcentral.com/search.php?do=finduser&u=410776

 

[Schlidel]

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]

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

# 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]

Yes! It works!

I had to make patchram executable, thanks.

You are incredible.

Sent from my LG-VM670 using Android Central Forums

 

[EarthnFire78]

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.

 

[mrg666]

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

 

[Schlidel]

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

 

[Tejer]

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?

 

[EarthnFire78]

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.

 

[mrg666]

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.

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.

 

[Dannemand]

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.

 

[reaper420]

I'm running the 5/08 build of mirage, for a while now I've been running gannons miui port, and I decided to switch back to mirage for a bit, well I was scrolling through the about phone menu and noticed it said my baseband is still zv5, I up dated to the new baseband or so I thought a couple of months ago, the flash went perfectly fine it said it was updated but I guess it wasn't, has anyone else had this issue



Sent from my LG-VM670 using Tapatalk 2

 

[Dannemand]

I'm running the 5/08 build of mirage, for a while now I've been running gannons miui port, and I decided to switch back to mirage for a bit, well I was scrolling through the about phone menu and noticed it said my baseband is still zv5, I up dated to the new baseband or so I thought a couple of months ago, the flash went perfectly fine it said it was updated but I guess it wasn't, has anyone else had this issue

Yeah, there was a huge discussion about it in LeslieAnn's radio patch thread: It turned out the radio-only update doesn't really take because it depends on the updated stock recovery to flash the radio image. You have to run the full Virgin Update (no jokes, please ) and run it TWICE - factory wipe in between. Then you root again with Jcase & Jerry's Gordita exploit. Then flash custom recovery and restore your favorite ROM.

A twist is that we found an incompatiblity between the new ZV9 radio and the IHO kernel, causing instability and sporadic reboots on texting and other radio tasks. But tdm, mrg666 and others finally nailed it. MiRaGe 05/08 and later has the new kernel. Also Bobz kernel v4 is compatible.

You can read more about it in that patch thread. Basically that ZV9 update was a big headache, though some us are seeing some signal improvement (we think )

 

[reaper420]

Yeah, there was a huge discussion about it in LeslieAnn's radio patch thread: It turned out the radio-only update doesn't really take because it depends on the updated stock recovery to flash the radio image. You have to run the full Virgin Update (no jokes, please ) and run it TWICE - factory wipe in between. Then you root again with Jcase & Jerry's Gordita exploit. Then flash custom recovery and restore your favorite ROM.

A twist is that we found an incompatiblity between the new ZV9 radio and the IHO kernel, causing instability and sporadic reboots on texting and other radio tasks. But tdm, mrg666 and others finally nailed it. MiRaGe 05/08 and later has the new kernel. Also Bobz kernel v4 is compatible.

You can read more about it in that patch thread. Basically that ZV9 update was a big headache, though some us are seeing some signal improvement (we think )

That's strange, I never bothered to check the baseband because at the time I thought I updated it my signal improved,I can text and receive calls from home now, I guess they fixed a tower or something near my house, thanks I'll check that thread out

Sent from my LG-VM670 using Tapatalk 2

 

[Dannemand]

@mrg666: I have to give it to you, that simply worked first try after updating brcm_patchram_plus and my build.prop. Bingo, just like that

Even without an Academy Award for Most Elegance in Bluetooth MAC Randomizing, this would already be a GREAT solution for me, just as it is. Having to do this when I update ROM is still nothing, considering that my wife I can both use our car now

Thanks a lot, man. Again!

 

[Glenar]

+1 on that.

Thanks. My wife thanks you too.