The Kernel Source Saga
aka
How Samsung Is Continuing to Violate the GPL
As you are all aware, there are still no custom kernels or any functioning custom recoveries for this fine (despite its flaws) device - the Samsung Galaxy Indulge (specifically, the SCH-R910). We'd love to be able to say that's not the case, but it is - and will continue to be, for as long as the issues outlined below continue. Samsung has left us not just in the lurch, but completely screwed - whether it is simple incompetence, disregard for the prepaid device community, interference by MetroPCS, or flat-out malice, the outcome is the same.
The Symptoms
The problem here is not that Samsung has not published some sort of source package. They have done at least that - enough to keep most observers happy. However, this package was broken from the start. The first package that Samsung published for the R910 included a badly-broken netfilter, which stumped our kernel experts for a good while before the decision was made to simply substitute the three pieces of netfilter from another device.
Doing this allowed our kernel developers (and myself) to compile a kernel, linked with a clean initramfs extracted from the stock kernel. In a properly-released source package, this should be enough - but it wasn't. These kernel attempts would appear to boot, but about 10-15s after completion of the boot animation, would die completely. The LTE and CDMA baseband versions, in About Phone, would display as Unknown, if one could get there quickly enough.
Three of the top Epic kernel developers, myself, and a long-time Android veteran analyzed kmsg logs (see below) and other factors, and determined that it was impossible to generate what is in the stock binary blob from the source package published by Samsung.
Warning: technical details! The following IRC log summarizes the issue:
[10:29] <@k0nane> The kernel now builds successfully - no more errors in netfilter, out of the box - but with the stock initramfs, it will exhibit the same behavior as previous builds. After boot, it will shut down within 10-15s. If there is time to get to About Phone, it will show the baseband versions as CDMA: unknown and LTE: unknown.
[10:30] <@k0nane> The modules that are built, which is not the complete set as in the stock initramfs, are /significantly/ larger than the stock copies and cannot be put in a kernel build as even with LZMA compression it will be far too large to fit in bml8.
[10:31] <@k0nane> So as before, if the solution is to use the (again, incomplete) newly-compiled modules, it's no solution at all. Thus there is still no way to build a kernel identical to the stock build.
[see logs below]
[10:36] <@k0nane> Expert analysis caught one of the anomalies:
[10:36] <@k0nane> <@Decad3nce> DRockstar: <4>[ 6.042947] [MULTIPDP][poll_thread] dpram_open failed!!
[10:36] <@k0nane> <@Decad3nce> probe never goes through
[10:36] <@k0nane> <@Decad3nce> and you fails
[10:36] <@k0nane> <@Decad3nce> :x
[10:36] <@k0nane> <@Decad3nce> what should happen (from start)
[10:36] <@k0nane> <@Decad3nce> <4>[ 6.275749] [MULTIPDP] dpram_open successd !!!!
[10:36] <@k0nane> <@Decad3nce> <3>[ 6.275770] [IDPRAM] <dpram_tty_ioctl:1718> IOCTL cmd = 0x5405
[10:36] <@k0nane> <@Decad3nce> <3>[ 6.280198] [IDPRAM] <dpram_tty_ioctl:1718> IOCTL cmd = 0x540
[10:36] <@k0nane> <@Decad3nce> which triggers phone active
[10:36] <@k0nane> <@Decad3nce> <3>[ 6.757528] [IDPRAM] <phone_active_irq_handler:2195> PHONE_ACTIVE level: LOW , phone_sync: 0
[10:36] <@k0nane> <@Decad3nce> then you have your power on, etc
[10:36] <@k0nane> <@Decad3nce> 3>[ 9.870551] [IDPRAM] dpram_phone_power_on() ...
[10:36] <@k0nane> <@Decad3nce> <3>[ 10.450069] [IDPRAM] <phone_active_irq_handler:2195> PHONE_ACTIVE level: LOW , phone_sync: 0
[10:36] <@k0nane> <@Decad3nce> <3>[ 10.457065] [IDPRAM] <phone_active_irq_handler:2195> PHONE_ACTIVE level: HIGH, phone_sync: 0
[10:36] <@k0nane> <@Decad3nce> also, not sure what this is
[10:36] <@k0nane> <@Decad3nce> <4>[ 6.042931] [MULTIPDP]filp_open() failed~!: -6
[10:36] <@k0nane> <@Decad3nce> doesn't occur in your goodlog
[10:36] <@k0nane> <@DRockstar> hmm, what could prevent the probe?
[10:36] <@k0nane> <@Decad3nce> the dpram_open failing
[10:37] <@k0nane> And to summarize that, "so from boot, goes through kernel init, then device init, then when it gets to the radio interface layer.. it dies a horrible death because of no access to dpram0"
[10:37] <@k0nane> The details should be unimportant, however, if what's provided is identical to/can produce stock (which, as we see, it cannot).
[10:39] <@k0nane> http://k0nane.info/size.png <== a comparison of stock (left) vs. compiled (right) module sizes
Click to expand...
Click to collapse
Logs: Bad Boot #1 Bad Boot #2 Clean Boot
Source and initramfs as of these logs: Github
What Has Samsung Done?
I have been in contact with SamsungJohn (John Imah), Samsung's official developer representative on Twitter. On first notification of the issue, no action had been taken, and it took an RT campaign to catch Mr. Imah's eye. Approximately one week later, Mr. Imah joined me in IRC, and took note of the information above. Shortly after that, Samsung released a new source package on opensource.samsung.com. That was great - except that the only difference was an end to the out-of-the-box compile errors. Everything else about this source package was identical. The results were the same.
Within the next business day, Mr. Imah requested that I send the information to his corporate email address, as he had an "HQ team" there with him. Unfortunately, that was June 22. Mr. Imah has not responded to tweets or DMs since then, and we have been given absolutely no indication that any work has been done on this issue. The source package has not been updated again.
I have given Samsung ample notification and time to work with myself and my fellow developers to resolve this issue without a public expose. They have failed to so much as maintain the appearance of progress, let alone make any. It was, is, time for the saga to end. Samsung is hereby on notice. They, by failing to provide the source necessary to generate what is included in the stock kernel binary, are violating the General Public License.
http://www.gnu.org/copyleft/gpl.html said:
You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:
- a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.
- b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.
- c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b.
- d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.
- e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.
Click to expand...
Click to collapse
How Can You Help?
Tweet, email, and otherwise contact every public-facing Samsung representative.
Tell your friends. Have them do the same.
Send a copy of this report to [email protected] - the source in question is the Linux kernel, which is owned by the Free Software Foundation.
Just spread the word - until Samsung feels the heat from this (feel free to contact their legal department!) we will not see results. Development for the Indulge will continue to be held back. Only the users will suffer.
--
Follow me on Twitter @k0nane/@publik0.
x-posted from AndroidForums.
for anyone that thinks this isnt worthwhile, imagine if your device had no source.. where would your kernels be? imagine if this became the trend, to give out crap source
shabbypenguin said:
for anyone that thinks this isnt worthwhile, imagine if your device had no source.. where would your kernels be? imagine if this became the trend, to give out crap source
Click to expand...
Click to collapse
And on top of that, I have every reason to believe - though IANAL - their behavior is illegal.
RT the thread.
I blew this up over on samsungs facebook page.. someone got pissed and deleted my post..
http://www.facebook.com/SamsungMobileUSA
I started to 'comment' on a bunch of their stuff w/ a link to this thread..
I might get my account suspended BWAHAHAHAHA..
bastards
Let's call out @samsungjohn on twitter!
Sent from my Epic™ 4G using XDA Premium app
This is the vary reason i will NEVER BUY any thing sumsuck ever makes, EVER AGAIN!
I have a suspicion that what's going on here is actually just a (possibly long-standing) bug. However, the situation is a bit strange all around.
To be specific, I suspect it's a race condition that happens to be triggered by your kernel build, but not Samsung's. This could easily be due to nothing more than using a different compiler, i.e., one that produces more efficient code.
I notice that in "Bad Boot #1" and "Bad Boot #2", the "[MULTIPDP][poll_thread] dpram_open failed!!" message is preceeded by "[MULTIPDP]filp_open() failed~!: -6". Looking at multipdp.c, dpram_open is failing to open "/dev/dpram1" and returning ENXIO ("No such device or address"), indicating that /dev/dpram1 doesn't exist yet.
Now, there's only two references to "/dev/dpram1" in the entire stock kernel image. The first is the line in multipdp.c that it's failing on. The second is in initramfs's /sbin/init. Here, Android's init actually contains a simplified implementation of udev to handle kernel uevents. That is, it's responsible for dynamically creating device nodes as kernel drivers are loaded, one of which is /dev/dpram1.
What I think is happening is this:
init.rc insmods dpram.ko
dpram.ko registers the dpram tty devices, issuing an add uevent message for device 252:2.
... (some time elapses) ...
init processes the uevent message, creates /dev/dpram1.
Meanwhile:
init.rc insmods multipdp.ko
multipdp.ko creates the poll_thread kernel thread.
poll_tread calls dpram_open.
dpram_open attempts to open /dev/dpram1, which might not exist yet.
Probably what's happening is that Samsung's kernel "takes long enough" to get to the "insmod multipdp.ko" part of init.rc that init has time to process the dpram.ko uevents and create /dev/dpram1, so that by the time dpram_open is called, the device node exists. However, your kernel is "fast enough" that init.rc gets to "insmod multipdp.ko", creates the new kernel thread and executes it, before init has caught up on device node creation. Thus, /dev/dpram1 doesn't exist and everything goes to ****.
Now here is where it gets bizarre. If we compare against the Epic's EC05 init.rc, there's an interesting stanza prior to module initialization that's missing here:
Code:
#samsung dpram modules
mknod 0666 /dev/dpram0 c 255 1
mknod 0666 /dev/dpram1 c 255 2
mknod 0666 /dev/dpramerr c 255 0
mknod 0666 /dev/ttyCDMA0 c 240 1
Presumably this is supposed to create the missing device nodes before insmoding both dpram.ko and multipdp.ko, eliminating the race condition. However, mknod is a command not supported by init, there's no mknod program in the initramfs, and those are the wrong device numbers. Perhaps it's an acknowledgment that the race condition exists on both devices, even though nothing is actually done on the Epic to avoid it? It's just, ... strange.
Unfortunately I can't think of a great solution. One option would be to modify multipdp.c to add a sleep loop around "filp_open(DPRAM_DEVNAME, ...)" to wait for the device to be created. However, that would mean using your own compile of multipdp.ko instead of the one Samsung provides, which could open a different can of worms.
A second option is to move "insmod /lib/modules/multipdp.ko" until after mounting /system, hoping that init would've caught up by then. This can even be insured by running a script that checks for the device node and sleeps if it doesn't exist yet. Something like:
Code:
#!/system/bin/sh
for i in 1 2 3 4 5; do
ls /dev/dpram1 && break
sleep 1
done
and call it from init.rc, after mounting /system, with:
Code:
exec /system/etc/wait_for_dpram1.sh
Anyways, even if this particular issue turns out not to be the culprit, I wouldn't be too quick to conclude that Samsung must've released bad/wrong/old source code. In general, building code with a different compiler, or even a different compiler version, can shake out unfortunate bugs like this. I really hate to ruin any good-will between Samsung and the community by making inflammatory acusations when, frankly, they're probably just as puzzled as we are over this.
Best of luck!
mkasick said:
I have a suspicion that what's going on here is actually just a (possibly long-standing) bug. However, the situation is a bit strange all around.
To be specific, I suspect it's a race condition that happens to be triggered by your kernel build, but not Samsung's. This could easily be due to nothing more than using a different compiler, i.e., one that produces more efficient code.
I notice that in "Bad Boot #1" and "Bad Boot #2", the "[MULTIPDP][poll_thread] dpram_open failed!!" message is preceeded by "[MULTIPDP]filp_open() failed~!: -6". Looking at multipdp.c, dpram_open is failing to open "/dev/dpram1" and returning ENXIO ("No such device or address"), indicating that /dev/dpram1 doesn't exist yet.
Now, there's only two references to "/dev/dpram1" in the entire stock kernel image. The first is the line in multipdp.c that it's failing on. The second is in initramfs's /sbin/init. Here, Android's init actually contains a simplified implementation of udev to handle kernel uevents. That is, it's responsible for dynamically creating device nodes as kernel drivers are loaded, one of which is /dev/dpram1.
What I think is happening is this:
init.rc insmods dpram.ko
dpram.ko registers the dpram tty devices, issuing an add uevent message for device 252:2.
... (some time elapses) ...
init processes the uevent message, creates /dev/dpram1.
Meanwhile:
init.rc insmods multipdp.ko
multipdp.ko creates the poll_thread kernel thread.
poll_tread calls dpram_open.
dpram_open attempts to open /dev/dpram1, which might not exist yet.
Probably what's happening is that Samsung's kernel "takes long enough" to get to the "insmod multipdp.ko" part of init.rc that init has time to process the dpram.ko uevents and create /dev/dpram1, so that by the time dpram_open is called, the device node exists. However, your kernel is "fast enough" that init.rc gets to "insmod multipdp.ko", creates the new kernel thread and executes it, before init has caught up on device node creation. Thus, /dev/dpram1 doesn't exist and everything goes to ****.
Now here is where it gets bizarre. If we compare against the Epic's EC05 init.rc, there's an interesting stanza prior to module initialization that's missing here:
Code:
#samsung dpram modules
mknod 0666 /dev/dpram0 c 255 1
mknod 0666 /dev/dpram1 c 255 2
mknod 0666 /dev/dpramerr c 255 0
mknod 0666 /dev/ttyCDMA0 c 240 1
Presumably this is supposed to create the missing device nodes before insmoding both dpram.ko and multipdp.ko, eliminating the race condition. However, mknod is a command not supported by init, there's no mknod program in the initramfs, and those are the wrong device numbers. Perhaps it's an acknowledgment that the race condition exists on both devices, even though nothing is actually done on the Epic to avoid it? It's just, ... strange.
Unfortunately I can't think of a great solution. One option would be to modify multipdp.c to add a sleep loop around "filp_open(DPRAM_DEVNAME, ...)" to wait for the device to be created. However, that would mean using your own compile of multipdp.ko instead of the one Samsung provides, which could open a different can of worms.
A second option is to move "insmod /lib/modules/multipdp.ko" until after mounting /system, hoping that init would've caught up by then. This can even be insured by running a script that checks for the device node and sleeps if it doesn't exist yet. Something like:
Code:
#!/system/bin/sh
for i in 1 2 3 4 5; do
ls /dev/dpram1 && break
sleep 1
done
and call it from init.rc, after mounting /system, with:
Code:
exec /system/etc/wait_for_dpram1.sh
Anyways, even if this particular issue turns out not to be the culprit, I wouldn't be too quick to conclude that Samsung must've released bad/wrong/old source code. In general, building code with a different compiler, or even a different compiler version, can shake out unfortunate bugs like this. I really hate to ruin any good-will between Samsung and the community by making inflammatory acusations when, frankly, they're probably just as puzzled as we are over this.
Best of luck!
Click to expand...
Click to collapse
.....and why are you not a recognized developer? You deserve it more than me.
mkasick, thanks for the reply, we will look into this. EDIT: Keep in mind that we are using the same toolchain as Samsung, specifically CodeSourcery 2009q3.
mkasick said:
I have a suspicion that what's going on here is actually just a (possibly long-standing) bug. However, the situation is a bit strange all around.
To be specific, I suspect it's a race condition that happens to be triggered by your kernel build, but not Samsung's. This could easily be due to nothing more than using a different compiler, i.e., one that produces more efficient code.
I notice that in "Bad Boot #1" and "Bad Boot #2", the "[MULTIPDP][poll_thread] dpram_open failed!!" message is preceeded by "[MULTIPDP]filp_open() failed~!: -6". Looking at multipdp.c, dpram_open is failing to open "/dev/dpram1" and returning ENXIO ("No such device or address"), indicating that /dev/dpram1 doesn't exist yet.
Now, there's only two references to "/dev/dpram1" in the entire stock kernel image. The first is the line in multipdp.c that it's failing on. The second is in initramfs's /sbin/init. Here, Android's init actually contains a simplified implementation of udev to handle kernel uevents. That is, it's responsible for dynamically creating device nodes as kernel drivers are loaded, one of which is /dev/dpram1.
What I think is happening is this:
init.rc insmods dpram.ko
dpram.ko registers the dpram tty devices, issuing an add uevent message for device 252:2.
... (some time elapses) ...
init processes the uevent message, creates /dev/dpram1.
Meanwhile:
init.rc insmods multipdp.ko
multipdp.ko creates the poll_thread kernel thread.
poll_tread calls dpram_open.
dpram_open attempts to open /dev/dpram1, which might not exist yet.
Probably what's happening is that Samsung's kernel "takes long enough" to get to the "insmod multipdp.ko" part of init.rc that init has time to process the dpram.ko uevents and create /dev/dpram1, so that by the time dpram_open is called, the device node exists. However, your kernel is "fast enough" that init.rc gets to "insmod multipdp.ko", creates the new kernel thread and executes it, before init has caught up on device node creation. Thus, /dev/dpram1 doesn't exist and everything goes to ****.
Now here is where it gets bizarre. If we compare against the Epic's EC05 init.rc, there's an interesting stanza prior to module initialization that's missing here:
Code:
#samsung dpram modules
mknod 0666 /dev/dpram0 c 255 1
mknod 0666 /dev/dpram1 c 255 2
mknod 0666 /dev/dpramerr c 255 0
mknod 0666 /dev/ttyCDMA0 c 240 1
Presumably this is supposed to create the missing device nodes before insmoding both dpram.ko and multipdp.ko, eliminating the race condition. However, mknod is a command not supported by init, there's no mknod program in the initramfs, and those are the wrong device numbers. Perhaps it's an acknowledgment that the race condition exists on both devices, even though nothing is actually done on the Epic to avoid it? It's just, ... strange.
Unfortunately I can't think of a great solution. One option would be to modify multipdp.c to add a sleep loop around "filp_open(DPRAM_DEVNAME, ...)" to wait for the device to be created. However, that would mean using your own compile of multipdp.ko instead of the one Samsung provides, which could open a different can of worms.
A second option is to move "insmod /lib/modules/multipdp.ko" until after mounting /system, hoping that init would've caught up by then. This can even be insured by running a script that checks for the device node and sleeps if it doesn't exist yet. Something like:
Code:
#!/system/bin/sh
for i in 1 2 3 4 5; do
ls /dev/dpram1 && break
sleep 1
done
and call it from init.rc, after mounting /system, with:
Code:
exec /system/etc/wait_for_dpram1.sh
Anyways, even if this particular issue turns out not to be the culprit, I wouldn't be too quick to conclude that Samsung must've released bad/wrong/old source code. In general, building code with a different compiler, or even a different compiler version, can shake out unfortunate bugs like this. I really hate to ruin any good-will between Samsung and the community by making inflammatory acusations when, frankly, they're probably just as puzzled as we are over this.
Best of luck!
Click to expand...
Click to collapse
You weed out toolchain, source, and what you have left is a defconfig that probably has more debugging active than the one that's shipped with the source.
No other way to explain size differential.
EDIT: Also, holy awesome on that analysis.
mkasick said:
One option would be to modify multipdp.c to add a sleep loop around "filp_open(DPRAM_DEVNAME, ...)" to wait for the device to be created.
Click to expand...
Click to collapse
Attached is a patch that should implement this. I've also attached a build of the kernel with it applied--given that we might be looking at funny race condition issues, it's probably worth seeing if the build environment has as much of an effect here.
Mind you, I don't have an Indulge and was unable to test. No idea if this actually works, but hopefully it's progress.
Now, if it does work, it's worth running a dmesg and looking for a "/dev/dpram1 does not exist yet, sleeping." just prior to "dpram_open successd !!!!". If that message isn't there, then it wasn't strictly the patch that contributed to a successful kernel, rather it's probably an artifact of the build.
Full disclosure:
The kernel sources are from SCH-R910_OpenSource.zip posted the Samsung open source page. The initramfs was extracted from this Odin repackage of the stock kernel, linked to from androidforums, although in retrospect I probably should've pulled it from k0nane's GitHub. It was compiled with CodeSourcery G++ Lite 2010q1-188 (EABI) on a Debian sid machine last updated sometime two weeks ago.
In additon to the aforementioned patch (indulge_multipdp_wait_for_dpram1.diff), I used another patch (indulge_no_ifdef_linux.diff) to get rid of the single "#ifdef linux" that trips up the eabi compiler and shouldn't be necessary with the gnueabi one. Otherwise, the only other source changes I made were to the CROSS_COMPILE variable in Kernel/Makefile and CONFIG_INITRAMFS_SOURCE in Kernel/arch/arm/configs/forte_01_defconfig to set the appropiate paths for those two.
I build the kernel once with the original initramfs, copied the newly-built modules/samsung/multipdp/multipdp.ko over the existing one in the initramfs, and rebuilt the kernel to link in the updated initramfs. That should be it.
k0nane said:
Keep in mind that we are using the same toolchain as Samsung, specifically CodeSourcery 2009q3.
Click to expand...
Click to collapse
Yes you're right.
I know that for the Epic's DI18 Samsung used what looked to be an in-house build of GCC 4.3.1 for the stock kernel even though they were recommending CodeSourcery in the source README. Apparently they switched to 2009q3-67 for Froyo and I never noticed.
Decad3nce said:
You weed out toolchain, source, and what you have left is a defconfig that probably has more debugging active than the one that's shipped with the source.
No other way to explain size differential.
Click to expand...
Click to collapse
The defconfig on my Github is identical to that of the package on opensource.samsung.com with the exception of LZMA compression being enabled and a path to the initramfs files being set.
mkasick said:
Attached is a patch that should implement this. I've also attached a build of the kernel with it applied--given that we might be looking at funny race condition issues, it's probably worth seeing if the build environment has as much of an effect here.
Click to expand...
Click to collapse
I'll pass this on to an Indulge user, or test it myself if I find a working microUSB cable first. Thanks. EDIT: No such luck! Died within 15s like most kernel builds do. Unfortunate. I can have the user acquire a log, but I am 95% certain no new info will be presented.
k0nane said:
Died within 15s like most kernel builds do.
Click to expand...
Click to collapse
Crud.
k0nane said:
I can have the user acquire a log, but I am 95% certain no new info will be presented.
Click to expand...
Click to collapse
I'd be curious if it contains any more statements about dpram_open, suggesting whether or not that patch had any effect. Or the built multipdp.ko even works.
Either way, if the device is automatically rebooting after 15 seconds, it's either hitting a kernel panic or something funny is going on with the watchdog. If we could get console output with a UART jig that would likely be helpful.
Can (stock) recovery be booted with a source-compiled kernel and survive for some length of time?
mkasick said:
I'd be curious if it contains any more statements about dpram_open, suggesting whether or not that patch had any effect. Or the built multipdp.ko even works.
Click to expand...
Click to collapse
I will acquire a log ASAP. A new copy of that kernel with adbd flipped to root on boot would be useful, as it's difficult to capture a full kmsg without it - I can generate it via your patch, or if you wish to substitute in the initramfs from my github, that's an option as well.
mkasick said:
Either way, if the device is automatically rebooting after 15 seconds, it's either hitting a kernel panic or something funny is going on with the watchdog. If we could get console output with a UART jig that would likely be helpful.
Click to expand...
Click to collapse
And unfortunately, building one is a bit beyond my skill level. I'd be willing to buy one. The jig should work for the Indulge, given it is essentially a Galaxy S device. I agree that it's most likely panicking - it would be helpful if there were some kind of output to the display as there is with Epic kernel panics.
mkasick said:
Can (stock) recovery be booted with a source-compiled kernel and survive for some length of time?
Click to expand...
Click to collapse
That has not yet been tested. There's a /system/bin/recovery and a recovery partition; as with the Epic and other devices, the partition should be triggered by the button combination on boot. I'll have a user flash a built kernel to bml9.
k0nane said:
or if you wish to substitute in the initramfs from my github, that's an option as well.
Click to expand...
Click to collapse
Attached is a build with your github initramfs.
k0nane said:
And unfortunately, building one is a bit beyond my skill level. I'd be willing to buy one. The jig should work for the Indulge, given it is essentially a Galaxy S device.
Click to expand...
Click to collapse
I have to read through that thread again, but I believe the simple version of the JIG is a 3.3v USB-to-serial converter along with a single resistor to activate the UART. I have some FT232 converters lying around, but they're 5v.
I'll order some parts and see if I can build one for myself in a week or so, as it would be useful for Epic debugging. If it works, we can work something out to get one sent your way.
k0nane said:
That has not yet been tested. There's a /system/bin/recovery and a recovery partition; as with the Epic and other devices, the partition should be triggered by the button combination on boot.
Click to expand...
Click to collapse
I'm thinking ~15 seconds is a somewhat strange time to die during boot. If recovery (with adb) runs stable, then the kernel works in a minimal environment. Perhaps some narrowing down of the boot sequence can be done from there?
Sorry to derail this but I'm cross posting here..
I sent an inquiry to the EFF to see if this is an issue that they can help with. Below is the response I received:
Rebecca said:
Rebecca S. Reagan [email protected] to me
show details 6:27 PM (12 hours ago)
Hi there!
Thank you for contacting the Electronic Frontier Foundation (EFF).
Unfortunately, we do not have the capacity necessary to take on open source issues like this one. The Electronic Frontier Foundation (EFF) is a small, grassroots legal advocacy non-profit focused on defending civil liberties and constitutional rights online with very limited resources. As such, we have a very important but narrowly focused mission and are not equipped to address all of the potential issues that escape our limited scope.
Regards,
Rebecca
Click to expand...
Click to collapse
I took a second look, found, and fixed another problem. Attached are more builds.
I compiled an unpatched kernel using 2009q3-67, decompressed it, and ran "strings" against both it and the stock kernel. I diffed the strings output to look for anything missing that I could grep for in the source tree. I found some things in "Kernel/arch/arm/mach-s5pv210/mach-aries.c" in the stock kernel that were missing from my build.
First were missing definitions for "dpram-device", "onedram", and "modemctl". The second were strings corresponding to the modemctl_cfg_gpio function, which is responsible for setting the "PHONE_ON", "CP_RST", and "PDA_ACTIVE" gpios. For these items to be included requires that CONFIG_SAMSUNG_PHONE_TTY and CONFIG_SAMSUNG_PHONE_SVNET be set in the kernel config file. Which they are (as "=m") in forte_01_defconfig.
Here's the problem: when build_kernel.sh runs "make defconfig", the both config options are missing in the resulting .config file. It turns out that as part of the reorganization that Samsung did to package the source release, they moved the onedram drivers from the Kernel source directory to the external module one, and dropped the Kconfig files that define these options. Without them, the build infrastructure assumes that all (useful) references those config options are removed from the all source files and purges them from the configuration. Except they're still needed by mach-aries.c, and without them, a key part to the kernel radio interface goes missing.
This definitely contributes to why the radio can't be brought up on boot. This may also cause the reboot after 15 seconds, although I'm not certain.
Anyways, I fixed this problem by adding stub entires for CONFIG_SAMSUNG_PHONE_TTY and CONFIG_SAMSUNG_PHONE_SVNET to Kernel/arch/arm/Kconfig, which allows those options to be preserved by "make defconfig". I've also verified that all the other purged config options aren't used in this source tree.
Attached is a patch containing the modified Kconfig, just apply and clean build as normal. I've also attached two kernel builds for testing, one with the stock initramfs and the other with k0nane's.
Some more notes:
While comparing strings, I noticed that Samsung appears to do some amount of source clean-up and reorganization in preparation of open source packages. For example, there's a bunch of files stored in a "forte" subdirectory for whatever driver that are moved up to the parent, e.g., "Kernel/arch/arm/mach-s5pv210/forte/mach-aries.c" is moved to "Kernel/arch/arm/mach-s5pv210/mach-aries.c". This alone shouldn't be a problem, but if it was done improperly, i.e., not all forte-specific changes were pushed to the parent, some functionality or device-specific bug fixes could be lost.
With regard to my earlier concern about there being a race condition, I'm uncertain at this point if it's actually a problem. It's possible that the missing device definitions are picked up from sysfs by init, and the relevant device nodes created that way. I haven't verified that this is the case, but given that the Epic should be vulnerable to the same condition, but we never observe it, perhaps it's not really an issue. Also, the reason why modules compiled from the source package are much larger than the ones shipped with the initramfs is that they're unstripped. Compiling with the "INSTALL_MOD_STRIP" environment variable defined results in them being stripped upon "make modules_install".
Hope that helps.
mkasick, you are a god. You've done the work that Samsung completely neglected to do - whether deliberately or not.
I suppose this thread can be closed, now. The changes have been pushed to my Github.
Thanks everyone for your input, and mkasick for fixing an obscure problem on a device you don't own!
Ive been reading on this and was curious. I know infuse and skyfire have this on there system. Looks Like WE HAVE SOME evidence that we do have this installed.
CHECK SECOND POST
Here is OG posted and what it doeshttp://forum.xda-developers.com/showpost.php?p=11763089
http://forum.xda-developers.com/showthread.php?t=1122569
Here is more info on it really starts on post 55 http://forum.xda-developers.com/showthread.php?t=1338733&highlight=Carrier+IQ&page=6
HERE IS HOW TO CHECK (CAPPY DOES HAVE SOME)
DOWNLOAD Supercurio Voodoo Carrier IQ detector at the market here is link(THIS IS MORE FOR OUR DEVICE) and what I used to find on my and my wife cappy
https://market.android.com/details?id=org.projectvoodoo.simplecarrieriqdetector
This one doesn't show any detected on our device
http://forum.xda-developers.com/showpost.php?p=17612559&postcount=110
HERE IS GOOD READING ABOUT
http://lifehacker.com/5863895/carri...everything-on-your-phone-and-how-to-remove-it
http://www.xda-developers.com/android/the-rootkit-of-all-evil-ciq/
http://androidsecuritytest.com/features/logs-and-services/loggers/carrieriq/
twolostminds said:
By now anyone who has an Android phone has heard about CarrierIQ, CIQ or IQAgent. Business Wire in London announced on June 8th:
For the few who may be scratching their heads wondering what CarrierIQ is...
Steve Topletz, a member of an international group of hackers, human rights workers, lawyers and artists that fights internet censorship and promotes the right to privacy has described it as follows:
Information on CarrierIQ can also be found in the ACS SFR Epic4G ROM discussion thread and a thread I started requesting information from Epic4G Dev's here.
References to CIQ have been found deeply embedded Epic4G
Code:
Provided by chris41g
to be effectively removed you only need to remove it from 4 files. it is referenced elsewhere scattered throughout... but the four main files are
DialerTabActivity.apk
ext.jar
framework.jar
services.jar
then in the kernels initramfs, you have to disable the service in the init.rc
Provided by mkasick
Here's all the files that reference "CIQ", "carrieriq", or "libiq" with instances unrelated to Carrier IQ removed:
/ (initramfs):
- init: /dev/ttyCIQ0 UART, presumably to communicate with radio.
- init.rc: Start iqmsd service if property:service.iq.active=1.
- lib/modules/dpram.ko: Implements ttyCIQ UARTs.
/system:
- app/DialerTabActivity.odex
- app/FactoryTest.odex
- bin/iqmsd
- framework/ext.odex
- framework/framework.odex
- framework/sec_feature.odex
- framework/services.odex
- lib/libiq_client.so
- lib/libiq_service.so
Of these, bin/iqmsd is a purpose-unknown daemon, and libiq_client.so & libiq_service.so the client & service native code. The client & service managed code is implemented in framework/ext.odex & framework/framework.odex respectively.
In addition, the following framework classes reference Carrier IQ in some fashion:
framework/ext.odex:
- org.apache.http.impl.client.DefaultRequestDirector
framework.framework.odex:
- android.inputmethodservice.InputMethodService
- android.net.http.Request
- android.webkit.{BrowserFrame,CallbackProxy,LoadLis tener,WebViewCore}
- com.android.internal.telephony.SMSDispatcher
framework.services.odex:
- com.android.server.BatteryService
- com.android.server.WindowManagerService
- com.android.server.am.UsageStatsService
Finally, libiq_service.so is used exclusively by framework/framework.odex (com.carrieriq.iqagent.client.NativeClient), and libiq_client.so is used by:
- bin/iqmsd
- framework/ext.odex (com.carrieriq.iqagent.service.IQService)
- lib/libopencore_player.so
Makes you wonder what might be in the closed source.
The Android platform, like Linux, is based on openness. I am calling on all Android developers, programmers, hackers and users to band together as a community and come forward with any information you may have on CarrierIQ.
I am asking all those with the knowledge and resources to delve deeper into this issue to please do so and help spread the truth.
For anyone who wishes to contribute confidentially and anonymously please email:
CIQINVESTIGATION @ VERIZON dot NET
Click to expand...
Click to collapse
I am going to start adding what ROMS have it and locations so that way we have handle on this thing for future reference. I need your guys help on what roms you are running and locations
These DO NOT have any CIQ
Andromeda3 (2.2 ) Froyo
Nothing found here. Not even empty libraries.
Serendipity VII (I9000XXJVO 2.3 Gingerbread)
Stock Froyo UCKB1
MIUI
ANY AOSP ROM
IF You find files under XBIN
I have and others have deleted or renamed the /system/xbin/iqbridged file and so far no adverse effects. Im not responsible if you do and bad thing happen.
FOR THOSE GETTING FILES UNDER
Test for: Android logcat debugging log
(LOGCAT, confidence 100)
just delete after each startup by doing this with Terminal Emulator
su
mount -o remount rw /dev/
rm /dev/log/*
OR
You could also try deleting the folder /dev/log (delete "log")
Do NOT delete /dev/
FOUND THESE *Using Supercurio Voodoo Carirer IQ DETECTOR
Cog 4.5.3 (I897UCKB1 2.2) Froyo
/system/xbin/iqbridged
Stock (I897UCKK4 2.3.5) Gingerbread
Stock (I897UCKF1 2.3.3) Gingerbread
/system/xbin/iqbridged
Serenity 6/6.1(I897UCKK4 2.3.5) Gingerbread
/system/xbin/iqbridged
FUSION XII (I897UCKK4 2.3.5) Gingerbread
Roms bineraries and daemons
/system/xbin/iqbridged
Pinnacle 1.3 (I897UCKH3 2.3.4) Gingerbread
Roms bineraries and daemons
/system/xbin/iqbridged
Andriod logcat debugging log
D/IQClient( 232): new IQClent()
Cognition 5 v2(I897UCKF1 2.3.3) Gingerbread
/system/bin/iqmsd
/system/lib/libiq_client.so
/system/lib/libiq_service.so
FASTY 3 KK4
/system/xbin/iqbridged
MaxQ/Sparko KK4
/system/xbin/iqbridged
It says that it's very difficult to turn off with Samsung devices but that there is an off switch. Where is it?
As I understand it, all Samsung android devices have it deeply embedded, so much so that removing the binaries will cause boot to fail. Sign me up for a removal tool. I'm not a dev, but this kind of garbage makes me wish I was. I wonder how much CIQ charges the NSA for their 'services'? Somebody call 60 Minutes....
OwenW71 said:
As I understand it, all Samsung android devices have it deeply embedded, so much so that removing the binaries will cause boot to fail. Sign me up for a removal tool. I'm not a dev, but this kind of garbage makes me wish I was. I wonder how much CIQ charges the NSA for their 'services'? Somebody call 60 Minutes....
Click to expand...
Click to collapse
+2
9CHAR
I just flashed stock froyo to my phone from gingerbread and did not see any libiq service or libiq client in the system/lib folder
Sent from my SAMSUNG-SGH-I897 using Tapatalk
bump for a true answer
sfernandez said:
bump for a true answer
Click to expand...
Click to collapse
Our phone does not have CIQ on it.
Sent from my Captivate
miztaken1312 said:
Our phone does not have CIQ on it.
Sent from my Captivate
Click to expand...
Click to collapse
Can you please elaborate on how you know this and what did you check to verify that we dont have it?
logging test app.by trevE
for the purpose of testing ciq
and by talking to the the other devs when i offered to help...
and by just reading and trying the things it says in the things you are reading...
TRusselo said:
logging test app.by trevE
for the purpose of testing ciq
and by talking to the the other devs when i offered to help...
and by just reading and trying the things it says in the things you are reading...
Click to expand...
Click to collapse
So thats everything u did? sorry Im hella slow this morning mind not working for SH**T
no prob.. no point doing what others have done. and cant know without asking.
TRusselo said:
logging test app.by trevE
for the purpose of testing ciq
and by talking to the the other devs when i offered to help...
and by just reading and trying the things it says in the things you are reading...
Click to expand...
Click to collapse
Thank you I added in OP trevE post about removing it so it others have concerns and some more reading..THANX AGAIN
This thread was reported, and I agree, I think this belongs in General, not Q&A.
Cognition
My Captivate is running Cognition 5.2. I ran the CIQ checks in the Logging Checker apk. The CIQ File List returns with three entries:
/system/bin/iqmsd exists!
/system/lib/libiq_client.so exists!
/system/lib/libiq_service.so exists!
Am I interpreting it right that my phone has CIQ? I have a screenshot, but it seems I need more posts before I can post it.
Max Tempest said:
My Captivate is running Cognition 5.2. I ran the CIQ checks in the Logging Checker apk. The CIQ File List returns with three entries:
/system/bin/iqmsd exists!
/system/lib/libiq_client.so exists!
/system/lib/libiq_service.so exists!
Am I interpreting it right that my phone has CIQ? I have a screenshot, but it seems I need more posts before I can post it.
Click to expand...
Click to collapse
Two CIQ libraries and a binary daemon - I'd say that's a pretty strong indicator that you do
Running Team Hacksung ICS.. Looks like it's clean, as nothing opened.
Is this for firmware 2.2 or just original stock?
Cognition 5 is based on the official release of 2.2 KB1
My Captivate is running Stock Samsung Froyo 2.2 KB1, I have a running application called Mobile Tracker Settings in my list that when I press force close does nothing but highlight the button blue. DOES NOT FORCE CLOSE. are you going to tell that's not odd?
Most people are running 2.3.3+ builds BASED OFF OF CYANOGENMOD 7's Kernel, which in turn if you read the articles would indicate that the CM Kernel's have the CIQ hooks removed already so CIQ is not present on ROM's based on Recent CyanogenMod updates.
Just because your phone doesn't have it doesn't mean it doesn't exist...
Stinking stuff this CIQ !
Of course, the concept itself already exists on every PC running windows - it is called error reporting. Every time you have a crash or software error, you get a pop-up that asks whether you want to send an error report. Ever see that?
The one BIG difference is that it GIVES YOU THE OPTION of not sending. I never send error reports. The situation here is a little more sneaky, because on the phones there is no pop-up that allows you to choose "Don't Send". Malware like keyloggers etc. use this to "evil" ends. So the problem is not that it may be for innocuous error collecting, but someone with savvy can actually use the CIQ via an app you download to collect this info.
Manufacturers need to stop this or provide ABSOULTE GUARANTEES that it will not be misused or cannot be hacked in form another app. And that is where my beef is with this S^&t peice of software. Unfortunately, this stuff is so rampant in everything any device collects data - including browsers like Chrome and PCs and iPads - we need an "OCCUPY S*^T DATA COLLECTION" movement to make this prominent.
Hello everybody,
I created this thread because I noticed a lot of people are busy with it, but not a lot of knowledge is shared about it.
Unfortunatly this board doesn't use the common way of implementing bluetooth, so bluetooth loading is giving problems with hciattach.
Already a lot of developers notices in the sources of the Samsung Galaxy Y Sources which can be downloaded from Samsungs contains a folder in hardware/broadcom which is called bt.
Also I noticed another bluetooth folder in the external packages in which broadcom also changed some code to the standard bluez stack.
I was able to find almost the exact source base at Code Aurora Forum so I was able to extract the commits which broadcom has added to the bluez stack.
The patch I extracted can be found here:
http://pastebin.com/Biv570y0
It still contains some Code Aurora stuff, because it's almost imposible to find the exact source base Samsung used.
But if you search for broadcom inside the patch you can find the additions broadcom made.
Also I'm searching for the glib source base they used, because in there broadcom also applied some changes, but haven't found the correct base yet.
Hopefully this forum will become one big pool of knowledge which everybody has so we can crack this problem very soon.
Because I saw a lot of people doing the same thing over and over because there isn't much shared about whats already tried.
So hopefully we can combine our forces on this one.
Greetings PsychoGame
nice idea
but what do we actually need to work upon? the bluetooth library files?
i heard broadcom had released test binaries ....will final their release be fixing bluetooth?
Regards
aNubhav
anubhavrev said:
nice idea
but what do we actually need to work upon? the bluetooth library files?
i heard broadcom had released test binaries ....will final their release be fixing bluetooth?
Regards
aNubhav
Click to expand...
Click to collapse
We need to work on reviewing the Bluetooth files in the source code and reverse engineer them to get the Bluetooth working. Broadcomm released test binaries for the chipset, not for the Bluetooth. Hope that helps you. They have not even released their first stable binary, much less their "final release". I think they have forgotten all about it for now and released the test binaries to ease pressure off their backs.
Whats the exact reason that bt is not working? Im a bit disconnected from this forum...
I guess its not detectable cuz unlike wifi this wont even show error :/
BTW nice sig
Indeed the test binaries which have been released by Broadcom are only applicable to the graphics chipset.
For bluetooth the only things we have available is the BCM4330 .hcd binary located in the /system/bin which is in someway loaded by btld.
Also in the kernel broadcom implemented their own form of rfkill which is called bcm-rfkill if I remember correct, but is found on the system in the folder /sys/class/rfkill/rfkill0.
And appart from that only the kernel sources which are provided in the GT-S5360 Opensource package is the only source we have at this time.
From those sources I extracted the patch I added in my first post.
Btld I think should create a hci socket on /dev/ttyS1 which it does in the stock firmware but doesn' t work on the ported versions.
In the logcat it shows an error when loading bluetooth which says something like failed to create hci socket.
I will post a logcat later for exact errors shown in my logcat.
Greetings PsychoGame
Code:
E/bluedroid( 1518): Failed to create bluetooth hci socket: Address family not supported by protocol (97)
Is any kind of documentation available? Maybe you could then change the protocol to a supported one.
PsychoGame said:
Hello everybody,
I created this thread because I noticed a lot of people are busy with it, but not a lot of knowledge is shared about it.
Unfortunatly this board doesn't use the common way of implementing bluetooth, so bluetooth loading is giving problems with hciattach.
Already a lot of developers notices in the sources of the Samsung Galaxy Y Sources which can be downloaded from Samsungs contains a folder in hardware/broadcom which is called bt.
Also I noticed another bluetooth folder in the external packages in which broadcom also changed some code to the standard bluez stack.
I was able to find almost the exact source base at Code Aurora Forum so I was able to extract the commits which broadcom has added to the bluez stack.
The patch I extracted can be found here:
http://pastebin.com/Biv570y0
It still contains some Code Aurora stuff, because it's almost imposible to find the exact source base Samsung used.
But if you search for broadcom inside the patch you can find the additions broadcom made.
Also I'm searching for the glib source base they used, because in there broadcom also applied some changes, but haven't found the correct base yet.
Hopefully this forum will become one big pool of knowledge which everybody has so we can crack this problem very soon.
Because I saw a lot of people doing the same thing over and over because there isn't much shared about whats already tried.
So hopefully we can combine our forces on this one.
Greetings PsychoGame
Click to expand...
Click to collapse
i said for u alls my tentatives about this !
Hello Whitexp,
I never meant to insult you in any way, and I'm sorry if I did that in any way.
I know you shared you're knowledge on this with me, because I have received a PM from you with what you already did.
But after our conversation about that I found out that some other people also tried out what you did with the same results.
That is why I started this topic so we have a central point where all the information is shared.
Also tomorrow I will create a post for you in which I explain what you already tried, so other people know this.
Greetings PsychoGame
whitexp said:
i said for u alls my tentatives about this !
Click to expand...
Click to collapse
PsychoGame said:
Hello Whitexp,
I never meant to insult you in any way, and I'm sorry if I did that in any way.
I know you shared you're knowledge on this with me, because I have received a PM from you with what you already did.
But after our conversation about that I found out that some other people also tried out what you did with the same results.
That is why I started this topic so we have a central point where all the information is shared.
Also tomorrow I will create a post for you in which I explain what you already tried, so other people know this.
Greetings PsychoGame
Click to expand...
Click to collapse
lol
nops
just said for u , i explain my tentaives
Thank you Whitexp,
I misread a little bit what you said, so I interpreted it a little bit wrong.
Then we'll just wait and see what everybody is trying to do.
I know what you already tried was:
- You replaced the bluetooth folder in /external with the folder which was supplied in the GT-S5360 Opensource 2 package from the Samsung opensource website and compiled it with the options given in the Readme. This was no succes, which I can confirm because I also tried it, but took the bluetooth folder from GT-S5360 Opensource update 3 with the same result.
Also the result in android logcat was no different from without the bluetooth folder applied so this error came up:
E/bluedroid( 1518): Failed to create bluetooth hci socket: Address family not supported by protocol (97)
- The second try you made was to use brcm_patchram_plus in combination with btld. Also this lead to a dead end. I haven't tried this myself, so I don't know what errors may have come up in the logcat.
- Third try was to use brcm_patchram_plus without the use of btld, so the way you find it on many of the other CM ports without succes. I can also confirm this and I believe it led to the same error in the logcat as with the first try.
As an addition I found out that the bluedroid error above is found in the android sourcecode in the file <androidsource>/system/bluetooth/bluedroid/bluetooth.c which compiles to the file libbluedroid.so. Also I found in the Android.mk the option BOARD_CUSTOM_BLUEDROID which makes android building possible with a customized bluetooth.c so a libbluedroid.so. An example of this can be found for example on the samsung cooper device: https://github.com/CyanogenMod/android_device_samsung_cooper . I think we may have to do something with this also, because I found that the android port also has strange behavior when copying over the libbluedroid.so from the stock firmware. With the compiled version CM boots without a problem, but with the libbluedroid.so from stock the boot process hangs early on in the bootproces which you can see if you pull a logcat from the device. It doesn't even make it to alsa initialization. To be honest I only tested this with clean compiled CM, so without the external/bluetooth folder replaced with the one from source. Today will test to see if the same happens if I replaced the external/bluetooth folder with the one from the Samsung Opensource package.
Greetings PsychoGame
GermainZ said:
Code:
E/bluedroid( 1518): Failed to create bluetooth hci socket: Address family not supported by protocol (97)
Is any kind of documentation available? Maybe you could then change the protocol to a supported one.
Click to expand...
Click to collapse
Unfortunately as far as I know theres currently no real developer documentation available on the board or bluetooth chip.
The only information which google comes up with is this small bit of information on the bluetooth chip and board:
- BCM21553:
http://www.broadcom.com/products/Cellular/3G-Baseband-Processors/BCM21553
http://pdadb.net/index.php?m=cpu&id=a21553&c=broadcom_bcm21553
- BCM4330
https://www.bluetooth.org/tpg/RefNotes/4330-PB10X-R1.pdf
http://www.broadcom.com/products/Wireless-LAN/802.11-Wireless-LAN-Solutions/BCM4330
Still no luck in getting bluetooth to work.
Even compiling the Android source with the Bluetooth package from the GT-S5360 Opensource in combination with libbluedroid.so from stock didn't do the job.
Still rendered the system unbootable:S.
My developing will be on a low speed in the weekend, so will try new things next week.
Also people who have suggestions are welcome to post over here, but don't spam the thread.
I hope to keep this thread as informational as possible for other porters as well so we have as much information as possible in a central place:good:
Greetings PsychoGame
Hello ppl ....
jst placing a small request here
could you please run - "rfkill list" in terminal and post your results....
results from both stock and cm7 builds are welcome....
if you get "rfkill" not found on terminal try install busybox ..
i just googled the
Failed to create bluetooth hci socket: Address family not supported by protocol (97)
error and came up with this ....
TIA
anubhav
Not the Combine from Half-Life
</joke>
Hello anubhavrev,
I'll add the output of the rfkill list here in a minute.
Today I'm going to work on the bluetooth problem again.
I've found some new clues, when executing a logcat on the btld and bluetoothd in the stock rom.
I thought lets return to the point it was still working, and put the bluetooth system through the logwrapper.
Currently I'm building CM7 again with the bluetooth line in the init scripts exactly the same.
When finished building and flashing I will pull a logcat again and try to see if the logwrapper on the bluetooth system spits out something different.
Greetings PsychoGame
anubhavrev said:
Hello ppl ....
jst placing a small request here
could you please run - "rfkill list" in terminal and post your results....
results from both stock and cm7 builds are welcome....
if you get "rfkill" not found on terminal try install busybox ..
i just googled the
Failed to create bluetooth hci socket: Address family not supported by protocol (97)
error and came up with this ....
TIA
anubhav
Click to expand...
Click to collapse
Hello everybody,
I thought I'll update on what I tried with bluetooth today.
It looks promising, but it might just be a dead end as well, I'll investigate this further later on.
What I did was study the code in brcm_patchram_plus.c, and found out that it uses the UART H4 interface for bluetooth.
I knew from kernel developing this was a kernel feature, so I thought lets take a look what a search in the default config comes up with.
And bingo the bluetooth UART H4 was disabled in the kernel, so what I did was enable it and compile the kernel again.
To initialize the bluetooth with brcm_patchram_plus I added the next line to the init script in place of the btld daemon:
service hciattach /system/bin/logwrapper /system/bin/brcm_patchram_plus --enable_hci --baudrate 3000000 \
--patchram /system/bin/BCM4330B1_002.001.003.0634.0652.hcd /dev/ttyS1
user bluetooth
group bluetooth net_bt_admin
disabled
Click to expand...
Click to collapse
This time bluetooth started initializing, but the logcat shows that it fails with the following error:
D/DTUN_CLNT( 2055): BTLIF_MAKE_LOCAL_SERVER_NAME return name: brcm.bt.btlif.9000
I/DTUN_CLNT( 2055): connect_srv ret:-1 server name:brcm.bt.btlif.9000
I/bluetoothd( 2054): connect: Connection refused
E/BluetoothEventLoop.cpp( 1538): get_adapter_path: D-Bus error: org.freedesktop.DBus.Error.ServiceUnknown (The name org.bluez was not provided by any .service files)
I just wanted to let everybody know what I'm up to.
Greetings PsychoGame
I have very good news for the GT-S5360 community and other devices with bcm21553 board.
It looks like bluetooth is partially working in my device.
I can scan and find other bluetooth devices in my surrounding, and are able to find the GT-S5360 on other devices as well.
At the moment this is as far as I got, so pairing with the device is still not possible and sending files to the device is also still not possible.
But the first step has been set.
I think I also know what the problem might be with the bluetooth unable to pair, but I don't have time to fix this over the weekend.
As I have said in another thread I'm already investing a great deal of free time into this project, so this weekend I'm gonna take a break again.
Monday I'll start getting all the other problems out so hopefully somewhere next week I'll get bluetooth fully functioning.
In my CM7 thread I'll be releasing a new build where the bluetooth is partially working, so if you want to check it out for yourself then I'll advice you to take a look in the build.
Greetings PsychoGame
PsychoGame said:
I have very good news for the GT-S5360 community and other devices with bcm21553 board.
It looks like bluetooth is partially working in my device.
I can scan and find other bluetooth devices in my surrounding, and are able to find the GT-S5360 on other devices as well.
At the moment this is as far as I got, so pairing with the device is still not possible and sending files to the device is also still not possible.
But the first step has been set.
I think I also know what the problem might be with the bluetooth unable to pair, but I don't have time to fix this over the weekend.
As I have said in another thread I'm already investing a great deal of free time into this project, so this weekend I'm gonna take a break again.
Monday I'll start getting all the other problems out so hopefully somewhere next week I'll get bluetooth fully functioning.
In my CM7 thread I'll be releasing a new build where the bluetooth is partially working, so if you want to check it out for yourself then I'll advice you to take a look in the build.
Greetings PsychoGame
Click to expand...
Click to collapse
Ohh..thats great bro :thumbup: sorry i dnt knw anythng abut build cm7 or related to cm stuff..
Bt one thing i knw U r best in devloping forum for sgy :thumbup:
Keep it Up :thumbup: N all d best bro
I knw one day we will get bugless cm. :thumbup: due to ur awsme work :thumbup:
Sent from my GT-S5360 using xda app-developers app
If anyone wants to help me in my bluetooth development hereby I write what I did to get it working up to the point I'm at, at the moment.
In the kernel the following options have been set to Y and the kernel has been recompiled:
CONFIG_BT=y
CONFIG_BT_L2CAP=y
CONFIG_BT_RFCOMM=y
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=y
CONFIG_BT_HIDP=y
CONFIG_BT_HCIUART=y
CONFIG_BT_HCIUART_H4=y
About the these I'm not sure if I should include them in the kernel or not. Officially our kernel already had rfkill, which is a bcm-rfkill.
The problem is that the bluetoothd daemon is not able to correctly communicate with this bcm-rfkill. When the options below are not included bluetooth starts but a few bluetooth crashes occur. When I include them I'm able to start bluetooth, but am not able anymore to find any devices, and also my device isn't detected by other bluetooth devices anymore. So I think we will need to do some modifications to make the bluetoothd compatible with bcm-rfkill. Also it it not possible to work without the bcm-rfkill and use the kernels rfkill because then bluetooth isn't able to start anymore at all.
CONFIG_RFKILL=y
CONFIG_RFKILL_INPUT=y
In the init scripts I have set the following things to work with brcm_patchram_plus:
# Set the correct bluetooth MAC Address
setprop ro.bt.bdaddr_path "/data/misc/bluetooth/.nvmac_bt.info"\
# permissions for bluetooth.
chown bluetooth bluetooth /data/misc/bluetooth
chown bluetooth bluetooth ro.bt.bdaddr_path
chown bluetooth bluetooth /dev/ttyS1
chmod 0600 /dev/ttyS1
chmod 0660 /sys/class/rfkill/rfkill0/state
chown bluetooth bluetooth /sys/class/rfkill/rfkill0/state
chown bluetooth bluetooth /sys/class/rfkill/rfkill0/type
service hciattach /system/bin/logwrapper /system/bin/brcm_patchram_plus --enable_hci \
--baudrate 3000000 --patchram /system/bin/BCM4330B1_002.001.003.0634.0652.hcd /dev/ttyS1
user bluetooth
group bluetooth net_bt_admin
disabled
oneshot
The bluetoothd line in the init.rc isn't changed, so you can just leave it untouched in the init scripts.
Hopefully we are all able to crack it.
Greetings PsychoGame