Hi @ all,
after an extensive testing period with different kernels i would like to share my experiences with you. After Updating to CyMod 0.2 (a german MOD) i was not able to charge my mobile in the cradle anymore. Without going too deep into details i can give you the following statements:
1) All FeaCore oder Phoenix based kernels don't recognize the charging cradle, that means the mobile don't get charged. (I used the following kernels: FeaCore 1.2; Phoenix OC/UV; NON OC; OC/UV vdd -Testkernel; Cranium V6 1900 MHz)
2) Stock-Kernels XXPKS / XXKPU gets the mobile to be charged and additionally switch the mobile into car mode. (Car mode: in the upper left corner appears a steering wheel -> mobile gets charged andthe display isn't switched off automatically)
Meanwhile i discovered that this behaviour doesn't depend on the kernel itself but depends on a "closed source samsung module. This module isn't used in the open source kernels e. g. Phoenixkernel (But this is only an assumption by me, and only the profis can tell) LINK: http://forum.xda-developers.com/showthread.php?t=980937 an in connection to that: http://forum.xda-developers.com/showthread.php?t=820275
*****************************************************************************************************************************************
EDIT: as mentioned above, there must be a kernel component / driver which is missing in the so called open-source-kernels. A friend of mine in the german forum sends me the following link, which contains perhaps the needed code:
http://bonsai.googlecode.com/svn-hi...nux-2.6.32.9/drivers/usb/gadget/fsa9480_i2c.h
May be this is the missing link to make the Phoenix kernel work with the cradle. But i'm too unexperienced to check it and really don't know where to start searching in the kernel's code. In another thread i've read that the choosen mode depends not on the pin assignment but on the delivered voltage at the pins. This voltage assignments to the pin is made by the cradles electronic.
***************************************************************************************************************************************
Maybe we can use the collected information to find a new approach to find a way to make the wonderful Phoenix-kernel work with the charging cradle.
Special Thanks go to:
a) Skywalker01, who supported me with his knowledge on every level, also with the english language
b) Cynob from Android-hilfe for his MOD and for his support to figure out the problem
c) Crybert for providing the slightly modified stock-kernel (Link: http://forum.xda-developers.com/showthread.php?t=1376388 )
and all the other members here and in the german Android-Hilfe-Forum
IT would be awesome if sakindia and manu0ver would implementiert these Codes which will let us use our cradle.
Gesendet von meinem GT-I9001 mit Tapatalk
New Infos from Skywalker01
to whom it may concern....
Hi,
....
I just compared the linked source code to the one that is in Samsungs I9001 sources. The file is named slightly different and it appears in 4 different locations. The appropriate location seems to be GT-I9001_Kernel\kernel\include\linux\i2c\fsa9480.h
While this is an original linux source and about 5 month NEWER than the version in the given link above the latter one is a special Samsung version with some modifications and quite a lot of additions.
It is also unclear if these sources derive from the very same generic kernel sources and if it will be sufficient just to exchange this single file. h files are only definitions and parameters, usually the accompanying program code files (fsa9480.c for example) will also need adaptation.
Best advice I can give right now is to post these infos to manveru0 or YardE so they can try to include this stuff into there I9001 custom kernels.
......
BIG THX to your efforts Skywalker01
Here you find the related code: http://bonsai.googlecode.com/svn-history/r471/trunk/kernel-src/linux-2.6.32.9/drivers/usb/gadget/fsa9480_i2c.h
Rhonin86 said:
to whom it may concern....
Hi,
....
I just compared the linked source code to the one that is in Samsungs I9001 sources. The file is named slightly different and it appears in 4 different locations. The appropriate location seems to be GT-I9001_Kernel\kernel\include\linux\i2c\fsa9480.h
While this is an original linux source and about 5 month NEWER than the version in the given link above the latter one is a special Samsung version with some modifications and quite a lot of additions.
It is also unclear if these sources derive from the very same generic kernel sources and if it will be sufficient just to exchange this single file. h files are only definitions and parameters, usually the accompanying program code files (fsa9480.c for example) will also need adaptation.
Best advice I can give right now is to post these infos to manveru0 or YardE so they can try to include this stuff into there I9001 custom kernels.
......
BIG THX to your efforts Skywalker01
Here you find the related code: http://bonsai.googlecode.com/svn-history/r471/trunk/kernel-src/linux-2.6.32.9/drivers/usb/gadget/fsa9480_i2c.h
Click to expand...
Click to collapse
I've changed the fsa9480.h file under /include/linux/i2c and compiled the OC Kernel with it. Everything went well so there are at least no functions in the header file which ain't listed in the fsa9480.c file under /drivers/misc/fsa9480.c
Here's the link to the full package with the new kernel, though I doubt this will work (see skywalkers statement about the header files):
WARNING: As this thread is in the I9000 forum I must warn you! This is a kernel/CWM package for the I9001 aka Galaxy S Plus. Do not flash this on a I9000 or you'll brick your phone!
http://www.mediafire.com/?9ea081eeu34cv9p
The output concerning fsa9480.c during the compile process was:
Code:
CC drivers/misc/fsa9480.o
drivers/misc/fsa9480.c: In function 'fsa9480_i2c_tx_data':
drivers/misc/fsa9480.c:344:2: warning: ISO C90 forbids mixed declarations and code
drivers/misc/fsa9480.c: In function 'fsa9480_i2c_rx_data':
drivers/misc/fsa9480.c:388:2: warning: ISO C90 forbids mixed declarations and code
drivers/misc/fsa9480.c: In function 'fsa9480_chip_init':
drivers/misc/fsa9480.c:460:2: warning: large integer implicitly truncated to unsigned type
drivers/misc/fsa9480.c:464:2: warning: large integer implicitly truncated to unsigned type
drivers/misc/fsa9480.c: In function 'usb_switch_show':
drivers/misc/fsa9480.c:612:2: warning: ISO C90 forbids mixed declarations and code
drivers/misc/fsa9480.c:619:2: warning: 'return' with no value, in function returning non-void
drivers/misc/fsa9480.c:626:3: warning: 'return' with no value, in function returning non-void
drivers/misc/fsa9480.c: In function 'usb_switch_store':
drivers/misc/fsa9480.c:657:2: warning: ISO C90 forbids mixed declarations and code
drivers/misc/fsa9480.c:687:1: warning: no return statement in function returning non-void
drivers/misc/fsa9480.c: In function 'disable_vbus_store':
drivers/misc/fsa9480.c:710:1: warning: no return statement in function returning non-void
drivers/misc/fsa9480.c: In function 'DefaultESNStatus_switch_store':
drivers/misc/fsa9480.c:886:1: warning: no return statement in function returning non-void
drivers/misc/fsa9480.c: At top level:
drivers/misc/fsa9480.c:1557:2: warning: initialization from incompatible pointer type
drivers/misc/fsa9480.c:264:1: warning: 'dev_attr_KiesStatus' defined but not used
drivers/misc/fsa9480.c:591:12: warning: 'get_current_mode' defined but not used
drivers/misc/fsa9480.c:888:1: warning: 'dev_attr_DefaultESNStatus' defined but not used
drivers/misc/fsa9480.c:921:1: warning: 'dev_attr_dock' defined but not used
drivers/misc/fsa9480.c: In function 'fsa9480_chip_init':
drivers/misc/fsa9480.c:461:5: warning: 'ret' may be used uninitialized in this function
in addition, there are links to what may be original sources (we need to check them if the kernel above won't work):
http://lxr.free-electrons.com/source/drivers/misc/fsa9480.c
and a patch:
https://lkml.org/lkml/2011/7/26/77
manveru0 said:
WARNING: As this thread is in the I9000 forum I must warn you! This is a kernel/CWM package for the I9001 aka Galaxy S Plus. Do not flash this on a I9000 or you'll brick your phone!
Click to expand...
Click to collapse
*SORRY* Guys... it was my fault ....
Could one of the admins move the topic in the right forum
There is no need to switch it. Here are also People with the same problem. Maybe you will start a new thread in 9000 section and link it to here so the can use the informations also.
Thanks Manu! I´ve installed the new kernel 4200 points in Antutu and I will check in around an hour if the cradle hopefully will work.
Have you any idea about the frontcam issues in skype? with stock rom and kernel it works but with cwm it will not work only the backside one.
unfortunately it doesn't work...
though the istallation precess works fine and without error the cradle denies to charge the phone.
Thx anyway Manveru0...
If you got something to test, post it and we'll try it to help you to get rid of this wrong interpretation of the Phoenix-Kernel.
The cradle was recognized from stock-kernel 2.3.4 due to information delivered in the german forum.... Maybe this ist another hint to follow...
For me the same. Installation without trouble but screen shut off as normal and no charging.
Gesendet von meinem GT-I9001 mit Tapatalk
Maybe this might help?
The car cradle works fine with stock 2.3.6! The screen is rotating and phone is charging. But there is no Samsung-car-app available for the i9001 :-( Strange, because the normal google-car-app works fine! (although I can't install it through the german market, as it is "not available in your country"?!?).
The only thing which still won't work is the audio-out :-( I tried some of the i9000 audio-out-switcher apps, but non of them worked. Audio still comming from the phone speaker.
manveru0 said:
I've changed the fsa9480.h file under /include/linux/i2c and compiled the OC Kernel with it. Everything went well so there are at least no functions in the header file which ain't listed in the fsa9480.c file under /drivers/misc/fsa9480.c
Here's the link to the full package with the new kernel, though I doubt this will work (see skywalkers statement about the header files):
WARNING: As this thread is in the I9000 forum I must warn you! This is a kernel/CWM package for the I9001 aka Galaxy S Plus. Do not flash this on a I9000 or you'll brick your phone!
http://www.mediafire.com/?9ea081eeu34cv9p
The output concerning fsa9480.c during the compile process was:
Code:
CC drivers/misc/fsa9480.o
drivers/misc/fsa9480.c: In function 'fsa9480_i2c_tx_data':
drivers/misc/fsa9480.c:344:2: warning: ISO C90 forbids mixed declarations and code
drivers/misc/fsa9480.c: In function 'fsa9480_i2c_rx_data':
drivers/misc/fsa9480.c:388:2: warning: ISO C90 forbids mixed declarations and code
drivers/misc/fsa9480.c: In function 'fsa9480_chip_init':
drivers/misc/fsa9480.c:460:2: warning: large integer implicitly truncated to unsigned type
drivers/misc/fsa9480.c:464:2: warning: large integer implicitly truncated to unsigned type
drivers/misc/fsa9480.c: In function 'usb_switch_show':
drivers/misc/fsa9480.c:612:2: warning: ISO C90 forbids mixed declarations and code
drivers/misc/fsa9480.c:619:2: warning: 'return' with no value, in function returning non-void
drivers/misc/fsa9480.c:626:3: warning: 'return' with no value, in function returning non-void
drivers/misc/fsa9480.c: In function 'usb_switch_store':
drivers/misc/fsa9480.c:657:2: warning: ISO C90 forbids mixed declarations and code
drivers/misc/fsa9480.c:687:1: warning: no return statement in function returning non-void
drivers/misc/fsa9480.c: In function 'disable_vbus_store':
drivers/misc/fsa9480.c:710:1: warning: no return statement in function returning non-void
drivers/misc/fsa9480.c: In function 'DefaultESNStatus_switch_store':
drivers/misc/fsa9480.c:886:1: warning: no return statement in function returning non-void
drivers/misc/fsa9480.c: At top level:
drivers/misc/fsa9480.c:1557:2: warning: initialization from incompatible pointer type
drivers/misc/fsa9480.c:264:1: warning: 'dev_attr_KiesStatus' defined but not used
drivers/misc/fsa9480.c:591:12: warning: 'get_current_mode' defined but not used
drivers/misc/fsa9480.c:888:1: warning: 'dev_attr_DefaultESNStatus' defined but not used
drivers/misc/fsa9480.c:921:1: warning: 'dev_attr_dock' defined but not used
drivers/misc/fsa9480.c: In function 'fsa9480_chip_init':
drivers/misc/fsa9480.c:461:5: warning: 'ret' may be used uninitialized in this function
in addition, there are links to what may be original sources (we need to check them if the kernel above won't work):
http://lxr.free-electrons.com/source/drivers/misc/fsa9480.c
and a patch:
https://lkml.org/lkml/2011/7/26/77
Click to expand...
Click to collapse
@manveru0: OK, so we were right that this won't work because it's just not enough. But it's the right direction and some additional changes still need to be made. The compiler warnings also seem to show that the used versions of fsa9480.c and fsa9480.h don't match. At least some of them.
I just had a look at the code in your given links above and analysed the code a little bit. Here are the results:
- the patch in the lkml link is already included in the latest version 3.2 of the lxr link
- BUT although this is a Samsung source code it is not meant for use with the Galaxy phones. It is just a generic linux kernel code and does NOT include the necessary "CAR_KIT" code.
- apart from an extremely different code architecture the fsa9480.c version that is provided in the I9001 sources DOES contain a lot of "CAR_KIT" references and is also much longer so this definitely seems to be the right code which we are looking for.
- the latter code can be found in kernel/drivers/misc and this is exactly the path where your compiler warnings derive from. So to my best knowledge and understanding you are already compiling the correct fsa9480.c code and there is "only" one step left: get rid of all the warnings so the code can work as intended.
- the ISO C90 warnings can generally be ignored as they just refer to programming style and standards which might be inappropriate for you anyway and definitely are for the author of the code ;-)
Just one example from line 612, original code is:
Code:
mm_segment_t fs = get_fs();
Replacing that with two lines, first declaration, then program code like this should remove the warning as ISO C90 is fulfilled:
Code:
mm_segment_t fs;
fs = get_fs();
Well, the latter version is kind of beginner's code for the slow-witted and every experienced hardcore-coder would just laugh at that but the same goes for the ISO C90 standard. Well, that's of course just my opinion. And that of a huge bunch of somewhat experienced coders I know
- you replaced fsa9480.h in include/linux/i2c which is included in kernel/drivers/misc/fsa9480.c. But looking at the code I found that it's a conditional include, the code actually says:
Code:
#if defined(CONFIG_MACH_ARIESVE) || defined(CONFIG_MACH_ANCORA) || defined(CONFIG_MACH_GODART)
#include <linux/fsa9480.h>
#else
#include <linux/i2c/fsa9480.h>
#endif
So as CONFIG_MACH_ARIESVE is defined in your FeaCore_config only include/linux/fsa9480.h is actually included by fsa9480.c.
- now I compared include/linux/fsa9480.h and include/linux/i2c/fsa9480.h and except for two additional empty lines and Windows EOLs in /linux/i2c instead of Linux EOLs in /linux the files are completely identical. This leads only to one conclusion: include/linux/fsa9480.h in the I9001 sources is the wrong version but only this one should be exchanged.
You could give this another try and I think here are still some grateful testers for a second test version. I'm not sure if this is really the final solution and end of the story but I can have another look at the new warnings of the compiler output with the proposed modification - if there are still any left.
An additional information...
Hi guys,
first of all thx to Skywalker for his efforts. Due to the fact that i'm not a coder or a develloper i just can support this thread by collecting information and keep this thread updated. Therefor here is another opinion from another member of this forum:
This will not work with any Cyanogenmod, Teamhacksung or other open source ROMs for any version of Android, as it calls a closed-source Samsung module that will not be present in these ROMs.
Because i search for the cause why my SGS+ wasn't charged in the car charging cradle after installing the so called Phoenix-Kernel. Then i found the decisive hint in your thread the highlighted text.
Where can i get more information about this fact ?
Thx in advance
Rhonin
Hi there, this won't affect charging, it only affects audio switching. Charging should be working independently of the audio switching.
Click to expand...
Click to collapse
Thx to TheBeano who created the thread for the problem with the audioplug
Cheers
Test kernel released
After some days of hard work I finally managed to setup a complete developer environment for successfully compiling my own kernel for the I9001.
I went to all the changes that manveru0 made to the original Samsung sources and implemented most of them, especially the OC/UV settings, the additional IO schedulers and CPU governors. I actually started my first version only 3 days ago, for details you can have a look at my sources on github:
https://github.com/skywalker01/Samsung-Galaxy-S-Plus
So I must give great thanks to manveru0 for all his efforts, without those this hadn't been possible so quickly.
I also added and changed some features like:
- adding two more governors
- enabling PPP and other net related support
- changing some features to internal kernel support instead of external module (like ARC4 and ECB encryption)
While doing all this and browsing the compiler configuration settings and manveru0's development history I noticed that he switched off a driver while testing the battery drain issue and obviously never enabled it again. It's the MSM battery driver which also contains a lot of code to handle the battery and charging modes of the phone including the CAR_KIT status.
In the stock kernels this is enabled as module so I did the same for my kernel version. With a good chance this could already solve the car kit issue. You are invited to test that, download and unpack the attachment to get the raw boot.img.
I hope you already know how to flash a kernel image with dd, it was described in several 9001 threads numerous times. Just for your convenience this is the command you can type in a shell on your PC:
Code:
adb shell su -c "dd if=/sdcard/boot.img of=/dev/block/mmcblk0p8"
But beware: this can brick your phone if not typed exactly like above, custom boot animations must be reinstalled, phone must be rooted and adb must be installed on your PC. And you must reboot the phone once of course.
Alternatively you can also use odin to flash the boot.img file: adb and rooting is NOT even required for this method and AFAIK there are also instructions for that somewhere in this forum. But I already gave you those via PM, didn't I ?
Last words: I didn't found any bugs or issues with this kernel so far but you never know and you can also test other things than the car kit if you like.
Thanks for your Great work. I will See when i coul try it.
IT would be nice if you could make a Flashable zip for to use with cwm.
Gesendet von meinem GT-I9001 mit Tapatalk
WOW - THX
Hi Skywalker01
first of all THX for your big effort.
I've already downloaded your testkernel an now i'm on the way to install it. Keep you informed...
cu later
Edith says: OK and here are the first results of your work:
The kernel works like a charme - no visible errors on the first view, but i'm really sorry to say:
the kernel denies to work with the car charging cradle :-(
I was very confident that it will work because of your discovery of the missing driver. But don't give up... i believe in your skills...
What about audio out?
Gesendet von meinem GT-I9001 mit Tapatalk
Audio out...
bikeaholics said:
What about audio out?
Gesendet von meinem GT-I9001 mit Tapatalk
Click to expand...
Click to collapse
Sorry, haven't test it yet due to the fact, that i have no connection to the car's radio. Maybe an external loudspeaker would do the job ? But AFAIR charging works but the audio out is another prob. Have a look to the following link: http://forum.xda-developers.com/showthread.php?t=980937
As i plugged the mobile in the cradle, the cradle wasn't recognized. That means no charging in progress and the steering wheel as an indicator for the car mode didn't appear... sorry
skywalker01 said:
After some days of hard work I finally managed to setup a complete developer environment for successfully compiling my own kernel for the I9001.
I went to all the changes that manveru0 made to the original Samsung sources and implemented most of them, especially the OC/UV settings, the additional IO schedulers and CPU governors. I actually started my first version only 3 days ago, for details you can have a look at my sources on github:
https://github.com/skywalker01/Samsung-Galaxy-S-Plus
So I must give great thanks to manveru0 for all his efforts, without those this hadn't been possible so quickly.
I also added and changed some features like:
- adding two more governors
- enabling PPP and other net related support
- changing some features to internal kernel support instead of external module (like ARC4 and ECB encryption)
While doing all this and browsing the compiler configuration settings and manveru0's development history I noticed that he switched off a driver while testing the battery drain issue and obviously never enabled it again. It's the MSM battery driver which also contains a lot of code to handle the battery and charging modes of the phone including the CAR_KIT status.
In the stock kernels this is enabled as module so I did the same for my kernel version. With a good chance this could already solve the car kit issue. You are invited to test that, download and unpack the attachment to get the raw boot.img.
I hope you already know how to flash a kernel image with dd, it was described in several 9001 threads numerous times. Just for your convenience this is the command you can type in a shell on your PC:
Code:
adb shell su -c "dd if=/sdcard/boot.img of=/dev/block/mmcblk0p8"
But beware: this can brick your phone if not typed exactly like above, custom boot animations must be reinstalled, phone must be rooted and adb must be installed on your PC. And you must reboot the phone once of course.
Alternatively you can also use odin to flash the boot.img file: adb and rooting is NOT even required for this method and AFAIK there are also instructions for that somewhere in this forum. But I already gave you those via PM, didn't I ?
Last words: I didn't found any bugs or issues with this kernel so far but you never know and you can also test other things than the car kit if you like.
Click to expand...
Click to collapse
Just flashed your kernel and for the moment everything works good. Why you don't make an own thread for it?
Gesendet von meinem GT-I9001 mit Tapatalk
+1 for opening a standalone thread for ur kernel sky
crybert said:
Just flashed your kernel and for the moment everything works good. Why you don't make an own thread for it?
Gesendet von meinem GT-I9001 mit Tapatalk
Click to expand...
Click to collapse
rayiskon said:
+1 for opening a standalone thread for ur kernel sky
Click to expand...
Click to collapse
It's still in testing phase but don't worry, I already considered an own thread as soon as I'm done with some additional ToDo's.
BTW: I just tried to compile with the alternative fsa9480.h like I proposed in post #10 but with that compiling fsa9480.c halts with severe errors (undeclared definitions). So these two files don't match and I am just searching for some other versions, like I9000 Samsung and CM sources.
About audio: I already found some posts that claim that the external audio feature doesn't work in any custom ROM like CM but at least charging is supposed to do. I will also investigate TheBeano's solution on that later but first things first. Without recognizing the car kit at all the audio issue is still to be postponed.
Does it work for you....
crybert said:
Just flashed your kernel and for the moment everything works good. Why you don't make an own thread for it?
Gesendet von meinem GT-I9001 mit Tapatalk
Click to expand...
Click to collapse
Does this mean that your phone recognizes the cradle ? That would be mysterious
Related
Just for fun and because I can, I started to work on recompiling the kernel for my Archos 10.1 (gen8) device.
I'm working with the Archos provided gen8_gpl_froyo source tarball.
Apart from some small stuff I could work out, like unterminated double quoted strings in config.in files, patches that don't apply to sources because the sources contain symlinks where files are expected, and of course the rounds of what-do-I-need-on-my-host (automake, texinfo, ...) - I got both a working kernel compile, and all the rest of the build.
I proceeded to menuconfig in some stuff I'd like to have in the kernel, as modules, like netfilter conntracking / NAT support, advanced (policy) routing, namespaces, nfsd. Also went smoothly.
I can successfully start that kernel on an existing Uruk 0.7 install, by untarring my self built modules over what Uruk comes with in /lib/modules/2.6.29-omap1/kernel, depmod that, and use the Uruk's /root/initramfs.cpio.gz together with my self built zImage for flashing through the recovery menu.
The system then boots up fine, I can verify it is running the kernel, I can load the netfilter conntracking / NAT modules, and even install an state ESTABLISHED rule which does what it should.
HOWEVER - and that's why I open this thread, there is constant chatter, coming from the kernel, being written to logcat. This uses quite a bit of CPU, probably for the logging work, so I rapidly reverted to the Uruk's own kernel.
What I would like to know, is whether somebody else has seen the following kernel messages in a similar scenario, and knows what I did wrong / how I can work around that?
Code:
03-06 15:33:56.816 I/cat ( 1020): <6>tmdlHdmiTxHdcpCheck 4245
03-06 15:33:56.816 I/cat ( 1020): <3>Bad input instance value returned in hdcp_check line 729
03-06 15:33:56.847 I/cat ( 1020): <6>tmdlHdmiTxHdcpCheck 4245
03-06 15:33:56.847 I/cat ( 1020): <3>Bad input instance value returned in hdcp_check line 729
03-06 15:33:56.878 I/cat ( 1020): <6>tmdlHdmiTxHdcpCheck 4245
03-06 15:33:56.878 I/cat ( 1020): <3>Bad input instance value returned in hdcp_check line 729
It is a constant repetition of these two lines, I just showed three instances so you can get a feel for the frequency from the timestamps.
The function names / messages are nowhere to be found in the archos released source code, nor in the modules compiled from there.
They reside in two module files that lie directly in /lib/modules/, named hdmicec.ko and hdmitx.ko
The hdmitx.ko module is loaded when I boot into my kernel. Loading hdmicec.ko by hand does not improve the situation. Also, under the normal Uruk 0.7 kernel, only the hdmitx.ko is loaded.
Update 7.3.: the situation stays the same after I modified my .config to be, except for the diverse modules I additionally selected, identical to the kernel /proc/config.gz found on Uruk 0.7. There seem to be several things missing that are in Uruk 0.7, i.e. the interactive CPU governor, and filesystem caches.
I also compared the loaded modules after boot, and apart from module size, it is the same list with Uruk 0.7 and my kernel.
Trying again to use my kernel, I also noticed that the tablet freezes as soon as I try to start WLAN. Still pings (on the g_ether USB connection I use), but the GUI is frozen and ssh connections, too.
It seems to me that the gen8_froyo_gpl source released by Archos is somewhat lacking...
Where can I find the Uruk 0.7 kernel tree, or some other kernel that is Known Good?
Latest kernel source you can find here:
http://sauron.pourix.com/UrukDroid/
conntrack/nat brakes compatibility with tiwlan kernel driver - witch is not part of kernel (but can be recompiled).
Anyway - entire wifi stock is a mess .. sadly
$aur0n said:
Latest kernel source you can find here:
http sauron.pourix.com /UrukDroid/
Click to expand...
Click to collapse
Thanks! What is the build system are you using?
I'm not exactly confident that the one I built from the Archos GPL package, is good.
But it seems to work! I successfully compiled your kernel, with your .config, and run that now. Wifi is working so far, my g_ether usb network connection works, too, and no funny hdmi messages are showing.
Now I'm going to build in some of the stuff I wanted of the networking stuff, and see what breaks wifi exactly. I would _love_ to have conntrack / NAT available.
Update built again with various networking stuff enabled, advanced routing and namespaces among them, but consciously NOT with conntracking. Guess what - tiwlan_drv.ko does not load! When triggered through the UI that results in an apparent complete hang, but when trying insmod from a shell it is benign. All in all that's good - the wlan problems probably don't have anything to do with conntracking, and I have a half way easy test case to start "bisecting" which build option makes it fail. Now if I only had more time today...
Anyway, thanks again Sauron for providing such a good basis for playing!
$aur0n said:
conntrack/nat brakes compatibility with tiwlan kernel driver - witch is not part of kernel (but can be recompiled).
Click to expand...
Click to collapse
After some compile / flash / test cycles I'm pretty convinced that anything which changes the layout / size of struct net_device or struct sk_buff, breaks that binary tiwlan_drv.ko thing - which is probably to be expected...
Some googling around, did not find me any source code to that tiwlan_drv.ko, only loads of people copying it around between various systems in binary form (argh...)
Do you have source for that module available, so I could try and recompile it when the struct layout changes?
Here's a list of config defines that should probably be left alone, gleaned from looking at the struct definitions:
Code:
options that change sk_buff:
CONFIG_XFRM=y
CONFIG_NF_CONNTRACK=n
CONFIG_BRIDGE_NETFILTER=n (switches on when enabling bridge driver,
but can be switched off separately - bridge
itself builds and module loads)
CONFIG_NET_SCHED=n (so no tc / traffic shaping / queueing)
CONFIG_NET_CLS_ACT=n
CONFIG_IPV6_NDISC_NODETYPE=n?
CONFIG_MAC80211=n
CONFIG_NET_DMA=n?
CONFIG_NETWORK_SECMARK=n
options that change net_device:
CONFIG_WIRELESS_EXT=y
CONFIG_NET_DSA=n
CONFIG_NETPOLL=n (switched on / needed by netconsole... sigh)
CONFIG_NET_NS=n (would love to have that, lxc could work well then...)
CONFIG_DCB=n
CONFIG_COMPAT_NET_DEV_OPS=y
You can try with this source
http://processors.wiki.ti.com/index.php/OMAP35x_Wireless_Connectivity_Release_Notes_beta_3_release
I haven't checked it - so I cant guarantee it will work. But If you could make it work - this would give us NAT on Uruk - so....
$aur0n said:
I haven't checked it - so I cant guarantee it will work. But If you could make it work - this would give us NAT on Uruk - so....
Click to expand...
Click to collapse
Thank you! I looked into the stuff a bit, it is certainly the right code set. It's a pretty huge pack overall, packing a kernel and userlevel stuff, even a copy of the iptables source , but I already located the driver itself...
I'll see that I extract the driver only parts into your kernel tree, somewhere under staging, and get it to build and maybe even work from there.
Will need some time to do that, and I'm rather busy with other work this week - next week maybe.
tiwlan_drv rebuild - no success so far
Hi $auron,
was able to take some time yesterday and today to work on the tiwlan_drv source code you pointed out. Unfortunately I did not get it to run.
I successfully built a module, inside your kernel tree, by incrementally dumping .c and .h files from the TI code drop into a subdir of drivers/staging/ and finding out which -DEFINES it needs to build, and some small code mangling was also neccessary.
However, the resulting module fails to properly load, first with some GPIO allocation message which I could get around (not present in the .ko file from Archos), and then in a request_irq call during initialization. Looking at that second failure point I notice that the more hardware / board oriented parts of the code look not at all like what objdump can tell me about the Archos binary...
Given my nonexistent ARM assembler skills, I cannot go forward at that point with ease, so I'm trying to chicken out by asking some Archos people for the source... No idea whether that will work...
UPDATE: no reply from Archos so far...
I try to sidestep the issue by moving the problematic elements of skbuff and net_device from the middle of the struct, to the end.
Hi!
I see that the topic is quite old - but anyway: are there any news? I am trying to build gen8 kernel with conntrack/nat support but with no luck - the kernel doesn't load, it reboots the device.
Did anybody find the way to compile with that options?
Golomidov said:
Hi!
I see that the topic is quite old - but anyway: are there any news? I am trying to build gen8 kernel with conntrack/nat support but with no luck - the kernel doesn't load, it reboots the device.
Did anybody find the way to compile with that options?
Click to expand...
Click to collapse
In Uruk 1.6 kernel has compiled in conntrack/nat.
$aur0n said:
In Uruk 1.6 kernel has compiled in conntrack/nat.
Click to expand...
Click to collapse
Yes, but there are other options that are missing in your kernel - targets owner and multiport - and because of that orbot transparent proxy doesn't work
Could you please tell how did you achieve that? I mean how did you compile UD kernel with conntrack/nat support?
(btw, I have changed init and installation scripts in UD for it to work with latest archos devices - a35dm for exmple)
EDIT: did you take/recompile tiwlan_drv.ko? would standard kernel work if I just copy tiwlan_drv.ko from UD?
---------- Post added at 03:06 PM ---------- Previous post was at 02:48 PM ----------
Golomidov said:
EDIT: did you take/recompile tiwlan_drv.ko? would standard kernel work if I just copy tiwlan_drv.ko from UD?
Click to expand...
Click to collapse
Nope, it didn't work
$aur0n said:
In Uruk 1.6 kernel has compiled in conntrack/nat.
Click to expand...
Click to collapse
$aur0n, could you please share the knowledge how did you manage to compile kernel with tiwlan driver and conntrack features?
Community will appreciate it! Thanks!
Golomidov said:
$aur0n, could you please share the knowledge how did you manage to compile kernel with tiwlan driver and conntrack features?
Community will appreciate it! Thanks!
Click to expand...
Click to collapse
It's all all written somewhere in developers thread of uruk droid.
$aur0n said:
It's all all written somewhere in developers thread of uruk droid.
Click to expand...
Click to collapse
Confirmed! tiwlan has been compiled and tested with nat/conntrack and targets owners and multiport.
Since openaos is down pasting here instruction:
Code:
How to build the WLAN source provided by archos
Kernel module released at http://gitorious.org/archos/archos-gpl-gen8/trees/master/hardware/ti/wlan/wl1271
Download the above mentioned sources.
cd .../hardware/ti/wlan/wl1271/platforms/os/linux
Now setup your environment by editing wl_env.bash or do it manually on the commandline in my case it was:
export CROSS_COMPILE=/usr/src/gen8/buildroot/build_arm/staging_dir/usr/bin/arm-linux-
export ARCH=arm
export HOST_PLATFORM=zoom2
export KERNEL_DIR=/usr/src/gen8/buildroot/linux/
Then type make and wait a few minutes and you are done. The tiwlan_drv.ko will appear in .../hardware/ti/wlan/wl1271/platforms/os/linux This gives you only the module. I am still looking at how the tiwlan_loader needs to be compiled.
More info can also be found http://omappedia.com/index.php?title=Wilink_Linux&redirect=no
If you use wl_env.bash then don't forget to
# source wl_env.bash
after editing and before make
thanks everybody!
I'm trying to get a functional config for the 1.2 mytouch but I'm having trouble tracking down the exact source to the MT3G-Fender-1.2-2.6.35.12-10M-test4.zip kernel but it's proving rather tricky. I can't seem to determine what the source to this kernel is and where to pull it.
If anyone can point me in the correct direction i can start on some work.
I pulled some pre-packaged git repo from ezterry's github. ezterry-kernel-biff-testing-5fba47e
I pulled my config from the running kernel from the zip i mentioned above running on my phone.
I built the kernel produced from using that config and the wlan.ko module.
Using this guide : http://forum.androidcentral.com/htc...how-build-your-own-kernel-package-source.html
I just want to be sure the kernel source i'm starting out with doesn't need extra patches that weren't included in the github pull in order to get it to work on the 1.2.
thanks for any help.
I'm also looking at cyanogenmod's github and will probably build a kernel against that pull this week as well.
Still, would like to know what sets the kernel i mentioned above apart from just straight pulls of these repos. That's the only part really confusing me.
Hey I was wondering if you could make this kernel your building an OverClock kernel too. No one has built one for our MyTouchs 1.2 that is truly for this device.
The Max OC I've been able to pull of is 725 without the phone freezing and rebooting.
Idk just thought it would be a good idea for your kernel!
Sent from my Fender using XDA Premium App
overclocking stability is less about the kernel and more about your particular hardware. Some phones just by manufacturing luck can achieve faster clocks than stock to varying degrees. 710 is considered to be the average max i believe. Anything faster is in the far minority of units. People who hack the cpufreq table to get these higher clocks limit to what they consider safe to stop people from actually destroying their hardware (which is possible).
Though, these "oc kernels" should have their patches posted somewhere. It's difficult to track down where exactly these kernel zips are coming from and thus to find out what their source is. Legally they need to either be shipped with the source or shipped with files pointing to the source or have the source available from the same place the binary was downloaded from. thus far I'm just guessing as to what the actual source is to the kernel i'm currently using and hoping all the necessary changes and patches are committed to the github that I believe the kernel is ultimately based from.
cellsafemode said:
I'm trying to get a functional config for the 1.2 mytouch but I'm having trouble tracking down the exact source to the MT3G-Fender-1.2-2.6.35.12-10M-test4.zip kernel but it's proving rather tricky. I can't seem to determine what the source to this kernel is and where to pull it.
If anyone can point me in the correct direction i can start on some work.
Click to expand...
Click to collapse
Hi I built this kernel.. later versions have a SOURCES file with the url's to the source I used. I added that after I started seeing it posted outside of the rom thread I originally posted it to
This is a build off of Pershoots github source
https://github.com/pershoot/kernel-2635
including Ezterry's 10Meg patch to the 32a mem map (Fender/1.2 is 32a/b hi-bred)
https://github.com/ezterry/kernel-b...9fca2404a4fa24384d11f8422ced65920bf06#L0R1355
and Farmatito's usb drain patches 001 - 022 excluding bfs
http://forum.xda-developers.com/showthread.php?t=1010932
and wlan.ko from Cyanogen's sources
the .config can be obtained using kernel-sources/scripts/extract-ikconfig
or adb pull /proc/config.gz config.gz
and as for Overclocking have a look at Dumfuq's githib
https://github.com/dumfuq/cm-kernel/commit/9f113c9e0acf19f57a35acbb85bd6f5cc2e76bb2
I get reboots at anything over 595
edit: I build these kernels because usb mount does not work with 2.6.34 on Gingerbread roms and more recent Cyanogen kernels had the green tint issue. Since the green tint issue is fixed and I think 2.6.34.8 works better on Froyo I haven't been working with 2.6.35 at all lately
cellsafemode said:
I'm trying to get a functional config for the 1.2 mytouch but I'm having trouble tracking down the exact source to the MT3G-Fender-1.2-2.6.35.12-10M-test4.zip kernel but it's proving rather tricky. I can't seem to determine what the source to this kernel is and where to pull it.
....
I just want to be sure the kernel source i'm starting out with doesn't need extra patches that weren't included in the github pull in order to get it to work on the 1.2.
Click to expand...
Click to collapse
you need to ask the person that build 2.6.35.12 based kernels.. [see ratkings comment]
My github has sources for 2.6.34.7/8 and 2.6.36.4 tags match my public builds (I think they are all tagged if not check the notes with my release of the kernel for the correct commit)
I also had some 2.6.35.9-11 builds from cm-kernel sources (exact commits and patches if needed mentions on the posts with the kernels) but the last one off those was in January.. and besides the january one the builds were 32b/2708+ only since that was the reason to re-build cm. sources with little modification.
I too get issues over 595. Wifi will not work etc. at 595 everything is happy.
I pulled the .config, and you cleared everything up. I was just wondering if those extra patches or anything that made booting to the 1.2 correctly were missing from the standard github kernels that I've found.
I have two jobs so time is very limited but I'm hopeful to boot my own compiled kernel this weekend and then work on modifying the accelerometer driver, specifically the parts that handle determining orientation in order to create a sysfs file that controls orientation locking. Write a 1 to the file and it always reports the same orientation that it's currently in, tricking the entire android system into thinking you are never changing your orientation... write a 0 and it reports the real orientation.. and so on. Then write a little app that can be used as a widget or kept in notification bar so you can easily tap lock the orientation whenever needed. Allowing true landscape and portrait locking on any mytouch 3g.
Uhh yeah I trimmed that way down.. no debugging at all (I like to live dangerously)
later tests were less insane
http://www.mediafire.com/file/eqgv0sbb7t4c57s/config-test7
the only other thing to note is that kernel/mkbootimg.sh was edited to force the base address to 10000000 instead of copying the address of the previous kernel.. thats really why I posted it as for Fender/1.2 only. I didn't want anyone messing that up and blaming me when re-flashing Pershoots kernel didn't correct it
It looks like the 1.2 patch is something that basically changes the 32A so if you patch your kernel source to support 1.2, you break building 32A kernels (you have to then have two trees or continually apply and remove the patch between builds). Is that the case, does the patch make your tree a 1.2 only tree when building for the 32A ?
If so I can edit the patch to introduce a kernel config under the saphire board selection to choose if you want to build for the mytouch 1.2 or 32A or 32B directly. So there is no confusion. Then instead of replacing values in the source like the patch does, wrap them in IFdef macros based on the kernel config options.
Then it should be easy to roll out 3 kernel compiles and do something similar to an auto kernel package and utilize a little logic to determine which to use. A rev board with 2.22 radio == 1.2 (i forget if there is another locale where the radio is different for the 1.2). Others can be chosen based on board rev only.
cellsafemode said:
It looks like the 1.2 patch is something that basically changes the 32A so if you patch your kernel source to support 1.2, you break building 32A kernels (you have to then have two trees or continually apply and remove the patch between builds). Is that the case, does the patch make your tree a 1.2 only tree when building for the 32A ?
If so I can edit the patch to introduce a kernel config under the saphire board selection to choose if you want to build for the mytouch 1.2 or 32A or 32B directly. So there is no confusion. Then instead of replacing values in the source like the patch does, wrap them in IFdef macros based on the kernel config options.
Then it should be easy to roll out 3 kernel compiles and do something similar to an auto kernel package and utilize a little logic to determine which to use. A rev board with 2.22 radio == 1.2 (i forget if there is another locale where the radio is different for the 1.2). Others can be chosen based on board rev only.
Click to expand...
Click to collapse
Um... all my kernels to my knowledge work on 32a old radio, 1.2/32b old radio and 2708+ 32b new radios..
Just 3 config files and #ifs for the changes.. ebi1=3.22 radio, ebi0=2.22 radio, and 2708+ = 32b with 2.22.27.08+ radios. (And thus 3 binaries in the auto kernels)
Note the ebi1/ebi0 have both 32a and 32b versions that is what you see with the smi size logic in the kernel
ok. I read the description of the 10M patch above wrong and thought it was also enabling 1.2 support ...
Also, I'm wondering why exactly we use an initrd/initramfs setup. Our rootfs drivers are all compiled in so what's the real reason we bother with initrd ? Seems like we could speed up loading time if we avoid having to decompress and use an initramfs image and just get right into mounting root
OK, sweet. I have 2.6.36.4-s2 working 100% on my mytouch 1.2. Now i can move forward with some actual development.
cellsafemode said:
Also, I'm wondering why exactly we use an initrd/initramfs setup. Our rootfs drivers are all compiled in so what's the real reason we bother with initrd ? Seems like we could speed up loading time if we avoid having to decompress and use an initramfs image and just get right into mounting root
Click to expand...
Click to collapse
i might be wrong but i think android mounts the partitions directly to places in the initrd. never does a switch root out of it like most linux distros.
but im a noob and might be wrong lol
tvall said:
i might be wrong but i think android mounts the partitions directly to places in the initrd. never does a switch root out of it like most linux distros.
but im a noob and might be wrong lol
Click to expand...
Click to collapse
The normal configuration is:
/ = ramdisk and contains init and adbd on the rom (and all of recovery)
/system = system partition
/cache = cache partition
/data = is userdata partition or internal MMC card depending on the device's design
/data/data = userdata if the device has an internal MMC card
** dream/sapphire only has /data on the MTD partition .. no internal MMC card.. just the external one (sd-card)
Can it be changed .. well that is more of a rom design than a kernel question.. just set the bootimage's command line to match if needed... but the above is aosp's expectation.
OK,
2.6.36.4-s2 ezterry kernel for mytouch 1.2
http://signal-lost.homeip.net/files/2.6.36.4-s2-cellsafe.zip.torrent
Source code at
http://signal-lost.homeip.net/files/ezterry_2.6.36.4-s2.torrent
Seed if you download. tTorrent app is a full torrent app for your phone. Or you can just load it on your computer (ideal) and then move it over usb while in recovery.
This is basically rattking's kernel install package with some minor asthetic edits to the install script and layout. The kernel is based off an older rattking .config with necessary changes to match configuration changes in the newer kernel as well as changes to certain schedulers and included drivers and features.
edit:
If you have trouble connecting to the torrent, make sure encryption is on.
IF you still have problems.. the direct link is http://signal-lost.homeip.net/files/2.6.36.4-s2-cellsafe.zip But it would be nice if the torrent was used.
edit2:
Some info about the latest kernel for those who haven't checked it out...
the 10M patch is already applied in the upstream source, so you'll have that. I also turned on all the unsafe frequencies, but default you move around between 122 and 595. You can override that however with user apps.
NOTE: Swap is not enabled with this kernel. .. that's about all the important stuff for now. I just wanted to get a good stable starting point before i start diving in and breaking stuff.
New version with some bugfixes.
I forgot to add in scsi support so the mass storage feature can function... some other minor changes too.
http://signal-lost.homeip.net/files/2.6.36.4-s2-cellsafe2.zip.torrent
7 hours of constant audio playback with the regular music player, on and off texting and web browsing over 3g (3g enabled entire time) and still got 50% power. I gotta compare to other kernels but that sounds pretty decent considering by now i'd be plugging the phone in.
my next half day off when i'm not 2 jobbing it i'll patch up the sensors so that I can enable and disable updating the orientation sensor via sysfs. Should be trivial then to have real orientation locking that's application independent. Should be sweet !
Is your kernel mainly for gingerbread, or froyo? If I understand right, ezTerry's 2.6.36.4 kernels are for gingerbread...
I've only tested it against gingeryoshi so I would say gingerbread or newer
I finally found a fix for wired tethering in Linux
A few of you may know that, for some reason, USB tethering with Linux stopped working after the update to Gingerbread. It still works with Windows, but Linux shows a 'bad crc' error in dmesg when USB tethering is activated. But someone figured out a fix, which I finally found and tested. I can confirm that it works with CM7 beta 2 using the built-in tethering option (and I am using it to write this post). The website where I found the patch did not mention what rom it was tested with, but since the patch is for a Linux module on the computer, it most likely won't matter.
Here is the website where I found the instructions - note that you will need to download the patch file, and make sure you have the Linux kernel source (that should be standard, but if you get an error about missing files...). Finally, be sure to pay attention to the punctuation used - code portions containing `uname -r` and M=`pwd` are NOT using the single quote - they are using the symbol located with the ~ (tilde) symbol, and this is extremely important. Anything contained in those symbols will be replaced with their output before execution of the command that contains them - similar to the use of parentheses in algebra.
The command uname -r returns the current kernel revision number, which is used to dynamically direct the commands to the most current source code.
`pwd` resolves to the Present Working Directory
If you prefer a more automated method, I have created a script that follows the commands from the above website, and packaged it with the patch file. Just extract both files into $HOME/Downloads (your Download directory in your home path), and run ./linux-rndis-patcher.sh - you may need to sudo chmod 0755 linux-rndis-patcher.sh first
I hope others find this as useful as I have. I take no credit - my contribution, the script, is a basic copy-and-paste job (tested and confirmed to work on the originating computer).
Update: the process works for the newer 3.2.0 kernel included in Linux 12.04, with slight modifications to match an updated directory structure in the source package. I updated my linux installation only to find that the old problem had returned. I am attaching a copy of the updated script - you can run it (make sure the patch file is in the correct directory) or simply use it as a command list.
Also, I should point out that this does not patch your kernel - it builds a patched stand alone module that can be used to override the built in version. This means it is easy enough to revert the process - more information is contained in the ubuntu wiki linked to from the site where I found the original information
Dude you are awesome, thank you for this!
Sent from my SPH-D700 using xda premium
Minor Correction
Well, I just realized that the script for 3.2 kernels didn't upload, but I can't get to my computer to fix that right now... so in the meantime, anyone who has upgraded to the 3.2 kernel can edit the 3.0 script
Two paths explicitly link to 3.0 directories, the just need to be changed to 3.2
Also, the path within the source code tree has changed - I will edit this post with the correct path momentarily, so stay tuned...
EDIT: I'm not sure what I was thinking about the path, but everything should be fine once both instances of "linux-source-3.0.0..." are edited to "...source-3.2.0"
Oh, and I renamed the patch file, so be sure to use the correct filename based on whether you download directly from the source or use the copy in my upload (identical aside from the filename)
Sent from my SPH-D700 using XDA
To clarify the bug here, the problem is that the Samsung Gingerbread USB gadget stack misspecifies a USB CDC union descriptor configuration that doesn't match what the device actually uses in RNDIS mode.
Windows, apparently, either ignores or doesn't care about the misconfiguration. Linux, while it's capable of detecting RNDIS interfaces in the absence of a CDC union description entirely, is "too strict" when the configuration is misspecified. So this patch makes Linux less strict in this regard.
So in short, the actual bug is in the device's kernel. But since RNDIS behavior is pretty much defined as "whatever Windows tolerates", it's reasonable and prudent to fix it on Linux USB hosts as well.
In any event, there's a few patches floating around for custom kernels to fix this problem on the device side, which is preferable as we don't really want to have to patch every Linux machine out there to deal with this issue. The one that we implemented for the CM9 kernel is here, and should've been included in our CM9 builds since alpha3 I believe.
Too true, I just haven't gotten around to figuring out how to patch the CM7 kernel yet so this works for me. Thanks for explaining the bug, so others will be aware that this is a workaround, not really a fix... I'll change the thread title, now that I think about it
Sent from my SPH-D700 using XDA
Yeah, there's a few changes in the CM9 kernel that need to be backported to CM7. Tortel is working on that now actually, so hopefully the next CM7 release will include the RNDIS fix among others.
Hi everyone,
I have been trying for quite a while now to compile HID Gadget support for my galaxy S3 and think i may be getting close. My current problem is that when i run insmod g_hid.ko i receive the following
Code:
insmod: init_module 'g_hid.ko' failed (Device or resource busy)
. The weird thing is that next time the screen turns off or if i attempt to insert it again the phone crashes (kernel panic i assume). I get this same error when i try and insmod g_zero.ko (although this one doesn't kill the phone). Can anyone tell me how i would attempt to debug this? Or even better, has anyone got g_hid working on there phone and if so, what modifications/kernel configs did you use?
Also, when compiling the kernel, in "USB gadget support" if i select any option other than Android Gadget in USB Gadget Drivers my kernel fails to build. Has anyone got any USB gadgets to compile and run and if so what procedure/modifications did you have to make. Currently i am compiling my kernel with android gadget selected as the usb gadget driver and then changing it to HID module and running make module_prepair and make module to get my .ko files (which may be why i am getting the above error).
If anyone can provide some insite and advice it would be greatly appreciated.
Thank you
Adrian
After months of trying, it appears i have got it solved. Unfortunately its not the most graceful solution and currently it disables MTP but i dont care. To fix it i searched every file in the kernel for mentions of CONFIG_USB_G_ANDROID and everywhere it was involved in an #if defined statement i added another section like so
Code:
#if defined(CONFIG_USB_ANDROID) || defined(CONFIG_USB_G_ANDROID) || defined(CONFIG_USB_S3C_OTGD)
In this case i added USB_S3C_OTG. As i said, it isn't pretty but it works.
Hope this helps someone in the future coz there is very little info on the net about this
Enjoy
Adrian
Code sample
I asked a question on Stack Overflow about exactly this issue. There is a small group of people who seem quite interested in this issue, and there really is not a lot of information on the net.
I would very much appreciate if you could explain in a little more detail what steps you took to get this to work for you. You could probably answer the Stack Overflow question more decisively than the current answers too: stack-overflow questions/9805731 - is-it-possible-to-program-android-to-act-as-physical-usb-keyboard. (I can't post the link as this forum blocks it.)
darcpyro said:
After months of trying, it appears i have got it solved. Unfortunately its not the most graceful solution and currently it disables MTP but i dont care. To fix it i searched every file in the kernel for mentions of CONFIG_USB_G_ANDROID and everywhere it was involved in an #if defined statement i added another section like so
Code:
#if defined(CONFIG_USB_ANDROID) || defined(CONFIG_USB_G_ANDROID) || defined(CONFIG_USB_S3C_OTGD)
In this case i added USB_S3C_OTG. As i said, it isn't pretty but it works.
Hope this helps someone in the future coz there is very little info on the net about this
Enjoy
Adrian
Click to expand...
Click to collapse
No worries, im happy to help. The funny thing is by reading the answers you got it started me on the right path to finding a solution. Im not sure how this will translate to other devices firmware but in the case of the galaxy S3 it was i went threw every file and added the
Code:
|| defined(CONFIG_USB_S3C_OTGD)
to all if defined statement that made any mention of CONFIG_USB_GADGET so that the code inside would be compiled. This was so that in the .config file for the kernel CONFIG_USB_GADGET would be set to yes and would then allow the hid driver to be compiled. Basically every time i got an error i saying something wasn't compiled or wasn't declared i went to that file, found where it was declared and added that if defined statement. I would upload my working source code but it would take weeks on my internet connection. If there is a specific file you want to see then let me know and i will post its contents.
Good luck
Adrian
darcpyro said:
No worries, im happy to help. The funny thing is by reading the answers you got it started me on the right path to finding a solution. Im not sure how this will translate to other devices firmware but in the case of the galaxy S3 it was i went threw every file and added the
Code:
|| defined(CONFIG_USB_S3C_OTGD)
to all if defined statement that made any mention of CONFIG_USB_GADGET so that the code inside would be compiled. This was so that in the .config file for the kernel CONFIG_USB_GADGET would be set to yes and would then allow the hid driver to be compiled. Basically every time i got an error i saying something wasn't compiled or wasn't declared i went to that file, found where it was declared and added that if defined statement. I would upload my working source code but it would take weeks on my internet connection. If there is a specific file you want to see then let me know and i will post its contents.
Good luck
Adrian
Click to expand...
Click to collapse
Hi Adrian
did you manage to use your android phone as a keyboard with USB_H_HID module ? I'm trying to do the same thing and I would be interested if you have more informations. For now, I had cyanogendmod source for Samsung Galaxy S III and I've compiled the default 10.1 ROM.
Yesterday, I tried to modify kernel options to include USB_H_HID in the kernel but the build fails on some android.c error.
See you
--
Thus0
Hi Thus0
I did manage to get it to work late last year (Just so you know that it can be done).From memory i basically ran grep over every file in the modules directory looking for CONFIG_USB_GADGET and then edited those files to say something like:
#if defined(CONFIG_USB_ANDROID) || defined(CONFIG_USB_G_ANDROID) || defined(CONFIG_USB_S3C_OTGD)
This way it would compile the USB Gadget modules as well. Let em know if you have any more questions and ill try and help.
Adrian
Huh – is it possible to make apk file for root devices?
Shir_man said:
Huh – is it possible to make apk file for root devices?
Click to expand...
Click to collapse
No sorry, as far as i know a custom kernal is compiled
darcpyro said:
No sorry, as far as i know a custom kernal is compiled
Click to expand...
Click to collapse
Is it possible to only use a driver and to load it with insmod in a stock rom? What modification require a custom kernel?
i was looking for a solution and ou,d something for the nexus 7
https://play.google.com/store/apps/details?id=remote.hid.keyboard.client
open xource here with kernel patch
https://www.google.com/url?q=https:...t&sa=D&usg=AFQjCNGztTd4-U4gHvd4DLzdg_qBxLb7gw
maybe someone can use it
You can use this link to find your model:
http://opensource.lge.com/osSch/list...ME&search=G710 <<< Find your model, you must use Linux to compile this code.
Models:
LMG710N - USA model (Carrier unlocked model)
LMG710PM - Pre-release codename Judy
LMG710PS - ?
LMG710AWM - Likely this was the AT&T model that was changed to the V35 ThinQ
LMG710TM - T-Mobile model
LMG710VM - Verizon model
The files are coded with R, P, & X which I am guessing is Release Candidate, Production, and scrapped version.
The readme files are really helpful in explaining how to compile the software.
Under the bootloader section:
This product includes cryptographic software written by "EDITED for Psuedo Privacy". This product includes software written by "EDITED for Psuedo Privacy".
I figured that we could either create a custom bootloader that's NOT encrypted, but still follows the same boot up process. If bootup requires an encryption, then we could set the the process to accept anything, for example: if encryption = 1 or 0 then proceed to bootup.
I hope this helps development on this phone in creating a kernel, custom roms, etc...
a) tar -xvzf LMG710TMP_Oreo_Android.tar.gz
- And, merge the source into the android source code
- Run following scripts to build android
a) source build/envsetup.sh
b) lunch 1
c) make -j4
When I get to this section of creating the ROM for the LMG710TM phone, and I run the make -j4 command, I get this error:
./frameworks/base/Android.mk:865: warning: FindEmulator: find: `frameworks/opt/telephony/src/java/android/provider': No such file or directory
./frameworks/base/Android.mk:874: warning: FindEmulator: find: `frameworks/opt/telephony/src/java/android/provider': No such file or directory
./frameworks/base/Android.mk:879: warning: FindEmulator: find: `frameworks/opt/telephony/src/java/android/provider': No such file or directory
./frameworks/base/Android.mk:884: warning: FindEmulator: find: `frameworks/opt/telephony/src/java/android/provider': No such file or directory
[720/988] including ./system/sepolicy/Android.mk ...
./system/sepolicy/Android.mk:107: warning: BOARD_SEPOLICY_VERS not specified, assuming current platform version
[978/988] including ./vendor/lge/external/android-clat-lg/Android.mk ...
build/core/base_rules.mk:238: error: vendor/lge/external/android-clat-lg: MODULE.TARGET.EXECUTABLES.clatd already defined by external/android-clat.
13:43:02 ckati failed with: exit status 1
build/core/main.mk:21: recipe for target 'run_soong_ui' failed
make: *** [run_soong_ui] Error 1
#### make failed to build some targets (53 seconds) ####
Also, when I am trying to make the Kernel for the same phone, based off of the open source files, I get this:
make[2]: *** [sub-make] Error 2
I have never built a ROM before. What am I doing wrong?
https://drive.google.com/open?id=1x0Bhn4qRnYOFdbI1BlghbNb6kS9N_Qy3 <<< Here is the READ ME file that comes with the OS for the LMG710TM.
bigjohnman said:
a) tar -xvzf LMG710TMP_Oreo_Android.tar.gz
- And, merge the source into the android source code
- Run following scripts to build android
a) source build/envsetup.sh
b) lunch 1
c) make -j4
When I get to this section of creating the ROM for the LMG710TM phone, and I run the make -j4 command, I get this error:
./frameworks/base/Android.mk:865: warning: FindEmulator: find: `frameworks/opt/telephony/src/java/android/provider': No such file or directory
./frameworks/base/Android.mk:874: warning: FindEmulator: find: `frameworks/opt/telephony/src/java/android/provider': No such file or directory
./frameworks/base/Android.mk:879: warning: FindEmulator: find: `frameworks/opt/telephony/src/java/android/provider': No such file or directory
./frameworks/base/Android.mk:884: warning: FindEmulator: find: `frameworks/opt/telephony/src/java/android/provider': No such file or directory
[720/988] including ./system/sepolicy/Android.mk ...
./system/sepolicy/Android.mk:107: warning: BOARD_SEPOLICY_VERS not specified, assuming current platform version
[978/988] including ./vendor/lge/external/android-clat-lg/Android.mk ...
build/core/base_rules.mk:238: error: vendor/lge/external/android-clat-lg: MODULE.TARGET.EXECUTABLES.clatd already defined by external/android-clat.
13:43:02 ckati failed with: exit status 1
build/core/main.mk:21: recipe for target 'run_soong_ui' failed
make: *** [run_soong_ui] Error 1
#### make failed to build some targets (53 seconds) ####
Also, when I am trying to make the Kernel for the same phone, based off of the open source files, I get this:
make[2]: *** [sub-make] Error 2
I have never built a ROM before. What am I doing wrong?
Click to expand...
Click to collapse
I've seen this error before. To fix it go to vendor/lge/external/android-clat-lg and find MODULE.TARGET.EXECUTABLES.clatd or something like that. Then just outline it but why are you making a rom for this phone? It supports project Treble
Basically it was just something I was trying to do to learn. If using project Treble has the framework that LG has so that I can use Quick Remote, LG Gallery, & LG Video, I may be set...
LameMonster82 said:
I've seen this error before. To fix it go to vendor/lge/external/android-clat-lg and find MODULE.TARGET.EXECUTABLES.clatd or something like that. Then just outline it but why are you making a rom for this phone? It supports project Treble
Click to expand...
Click to collapse
but treble aosp NEVER is as good as a normal rom
Did anybody managed to compile the kernel for G7?
I have managed to compile the kernel but so far was not able to make it work. I have a boot.img compiled and flashed to a/b partitions but phoen get stuck in fastboot mode. Any clue?
sign this petition to LG if you have a LG G7
https://www.change.org/p/lg-electro...share_options_more.control&utm_term=triggered
umminkug said:
https://www.change.org/p/lg-electro...share_options_more.control&utm_term=triggered
Click to expand...
Click to collapse
Done and shared to FB!
@LameMonster82 What did you mean by outline the MODULE.TARGET.EXECUTABLES.clatd ? I'm like @bigjohnman trying to learn, but Im not entirely hip to the what you mean. Any help would be appreciated!! thanks (I also have the T-mobile LG G7)
Dvalin21 said:
@LameMonster82 What did you mean by outline the MODULE.TARGET.EXECUTABLES.clatd ? I'm like @bigjohnman trying to learn, but Im not entirely hip to the what you mean. Any help would be appreciated!! thanks (I also have the T-mobile LG G7)
Click to expand...
Click to collapse
Hate to break it to you but the open source kinda doesn't work. I already tried it long time ago. Also I don't think you can test it at all with a non European model. If you still want to learn how to build a rom you can Google how to make GSI roms. You can start from here https://github.com/phhusson/treble_experimentations/wiki/How-to-build-a-GSI?
AWM is Canadian in case anyone is wondering
Any update on this?
LameMonster82 said:
Hate to break it to you but the open source kinda doesn't work.
Click to expand...
Click to collapse
Someone asked me to make a custom kernel for G7 so I took a look.
From what I can see it must be a snapshot of a very early development stage. It's not based on any CAF tag because it's actually older
than the very first CAF release for sdm845.
I read Pie might be out soon, maybe that source will be ok.
askermk2000 said:
Someone asked me to make a custom kernel for G7 so I took a look.
From what I can see it must be a snapshot of a very early development stage. It's not based on any CAF tag because it's actually older
than the very first CAF release for sdm845.
I read Pie might be out soon, maybe that source will be ok.
Click to expand...
Click to collapse
Do you think it's possible to merge the source with the latest CAF or at least the first official one? In case the pie source packs the same kernel source.
LameMonster82 said:
Do you think it's possible to merge the source with the latest CAF or at least the first official one? In case the pie source packs the same kernel source.
Click to expand...
Click to collapse
That might be possible, yes. Although there's no telling how far off LG's own code is from current and what effect that would have.
If they do the same with Pie then the best thing would be to simply e-mail them asking for current source drop.
I've done it before with the G5, they responded rather quickly as well. After all they are legally bound to.
I think they're just lazy about it in general. Probably don't expect anyone to care.
Edit: Well, not e-mail but send an inquiry. You'll find an icon next to the download links ("http://opensource.lge.com")
askermk2000 said:
That might be possible, yes. Although there's no telling how far off LG's own code is from current and what effect that would have.
If they do the same with Pie then the best thing would be to simply e-mail them asking for current source drop.
I've done it before with the G5, they responded rather quickly as well. After all they are legally bound to.
I think they're just lazy about it in general. Probably don't expect anyone to care.
Edit: Well, not e-mail but send an inquiry. You'll find an icon next to the download links ("http://opensource.lge.com")
Click to expand...
Click to collapse
Hi, unfortunately the pie kernel is also not working. J0sh1x tried it. I already send an email to LG but it takes so long for them to respond I got an automatic email reinsuring me that they will eventually respond.
Do you think that the pie kernel can run on Oreo?
LameMonster82 said:
Hi, unfortunately the pie kernel is also not working. J0sh1x tried it. I already send an email to LG but it takes so long for them to respond I got an automatic email reinsuring me that they will eventually respond.
Do you think that the pie kernel can run on Oreo?
Click to expand...
Click to collapse
What did he try exactly?
I'm building it now, there are many compilation errors and I have a slow pc, but I'm getting there.
I was imagining that after if successfully completes, it should work. This is considering I checked out the source beforehand,
and this time there's no pre-caf weirdness going on at least. It's based on LA.UM.7.3.r1-06100-sdm845.0
But ofc, if there is something else going on, like incomplete LG patchset...
Don't know about Oreo, or I don't know what kind of changes there are in Pie and if they can cause troubles.
Edit: Oh, I assume he tried it on Oreo then... I thought first someone could try it on Pie but only Korean variant has the beta ?
I don't have a G7 so...
The source seems ok. Probably doesn't work on Oreo because it's a Pie kernel, and/or changes done.
askermk2000 said:
What did he try exactly?
I'm building it now, there are many compilation errors and I have a slow pc, but I'm getting there.
I was imagining that after if successfully completes, it should work. This is considering I checked out the source beforehand,
and this time there's no pre-caf weirdness going on at least. It's based on LA.UM.7.3.r1-06100-sdm845.0
But ofc, if there is something else going on, like incomplete LG patchset...
Don't know about Oreo, or I don't know what kind of changes there are in Pie and if they can cause troubles.
Edit: Oh, I assume he tried it on Oreo then... I thought first someone could try it on Pie but only Korean variant has the beta ?
I don't have a G7 so...
The source seems ok. Probably doesn't work on Oreo because it's a Pie kernel, and/or changes done.
Click to expand...
Click to collapse
I also tried compiling it and it went buttery smooth. BTW any ideas of how to test it without opening the phone itself?
LameMonster82 said:
I also tried compiling it and it went buttery smooth.
Click to expand...
Click to collapse
Sure, if you use gcc 4.9... (or perhaps an older version of clang).
EDIT: I've built a test for anyone interested. (Just a stock kernel basically, sans exfat, for now)
I don't know how/what exactly LameMonster82 or J0sh1x did, but perhaps I've done something different...
Anyway, I did not really consider to build this for Oreo. For Pie it probably works, when that get's released.
This thing flashes modules as well (assumed to be /system/lib/modules), so if you test on Oreo you should back up those,
as it'll likely not work and then you'll be without working modules.
Finally; there's a lot of new stuff that's completely new to me now I see. Like vendor partition, dtbo, new ramdisk layout etc...
so maybe I've done something wrong, or did not do something necessary.