Database Users

[Q] Trying to recompile Hastarin for SuperRAM with CIFS: Issues

*EDIT*
Solved, new thread with download here: http://forum.xda-developers.com/showthread.php?t=887567
*/EDIT*
Hey everyone,
I'm trying to re-compile the Hastarin kernel for DarkStone1337's SuperRAM 1.5 to include CIFS support. I've compiled many a linux kernel, but never for Android, so can anyone point out what I'm doing wrong? Here are the commands I've run through:
Added android-ndk-r5/toolchains/arm-eabi-4.4.0/prebuilt/linux-x86/bin to PATH
git clone git://gitorious.org/~hastarin/linux-on-wince-htc/hastarins-linux_on_wince_htc.git
Grabbed DarkStone1337's patch from: http://pastebin.com/6qjkb4Hh
Renamed hastarins-linux_on_wince_htc to "a" to match the patch
patch -p0 < patch.txt (This did report a pre-mature ending on the patch, but everything appears to have patched OK)
make
The result:
arch/arm/mach-msm/built-in.o: In function `dex_cb_interrupt':
/files/Software/Android/hastarin/source/a/arch/arm/mach-msm/dex_comm.c:248: undefined reference to `notify_vbus_change_intr'
make: *** [.tmp_vmlinux1] Error 1
Click to expand...
Click to collapse
Any ideas?
Thanks,
B.

Hi!
Try using this toolchain instead! http://www.codesourcery.com/sgpp/lite/arm/portal/release1293
Then follow these commands to build the kernel:
make clean
make ARCH=arm htcleo_defconfig
Then change what is necessary to add the CIFS support
make ARCH=arm CROSS_COMPILE=/path-to-toolchain/bin/arm-none-linux-gnueabi- zImage
Taken from: http://htc-linux.org/wiki/index.php?title=QuickDeveloperStartGuide#Kernel
Then follow the same guide I linked to, to create the modules.

Hey Darkstone i saw the thread for SuperRAM 1.5 has been closed requested by you. Was there a major reason? Are we not supposed to use it anymore or was it put on hold. just asking because Im still testing it out and its been rock solid after several reboots.

PENKO956 said:
Hey Darkstone i saw the thread for SuperRAM 1.5 has been closed requested by you. Was there a major reason? Are we not supposed to use it anymore or was it put on hold. just asking because Im still testing it out and its been rock solid after several reboots.
Click to expand...
Click to collapse
prob due to folks refusing to read and do a little research before posting common problem Roth common fixes...

DarkStone1337 said:
Hi!
Try using this toolchain instead! http://www.codesourcery.com/sgpp/lite/arm/portal/release1293
Then follow these commands to build the kernel:
make clean
make ARCH=arm htcleo_defconfig
Then change what is necessary to add the CIFS support
make ARCH=arm CROSS_COMPILE=/path-to-toolchain/bin/arm-none-linux-gnueabi- zImage
Taken from: http://htc-linux.org/wiki/index.php?title=QuickDeveloperStartGuide#Kernel
Then follow the same guide I linked to, to create the modules.
Click to expand...
Click to collapse
First off, thanks a ton for responding, this was very helpful. Secondly, sorry for the threadjackers. Lastly, this both works, and doesn't. The following works fine:
# git clone git://gitorious.org/~hastarin/linux-on-wince-htc/hastarins-linux_on_wince_htc.git
# make CROSS_COMPILE=/files/Software/Android/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi- ARCH=arm clean
# make CROSS_COMPILE=/files/Software/Android/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi- ARCH=arm htcleo_defconfig
# make CROSS_COMPILE=/files/Software/Android/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi- ARCH=arm zImage -j 4
Click to expand...
Click to collapse
But when I try to make an exact copy of the kernel you created for SuperRAM 1.5 (without modifying for CIFS), it doesn't, so I must be doing something wrong. Here was my process there:
# git clone git://gitorious.org/~hastarin/linux-on-wince-htc/hastarins-linux_on_wince_htc.git
# mv hastarins-linux_on_wince_htc a
# cd a
# patch -p0 < patch
(Stripping trailing CRs from patch.)
patching file a/arch/arm/mach-msm/qdsp6_1550/q6audio.c
(Stripping trailing CRs from patch.)
patching file a/drivers/video/msm/gpu/kgsl/kgsl_ringbuffer.c
patch unexpectedly ends in middle of line
patch: **** malformed patch at line 786:
# make CROSS_COMPILE=/files/Software/Android/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi- ARCH=arm clean
# make CROSS_COMPILE=/files/Software/Android/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi- ARCH=arm htcleo_defconfig
# cp ../../config ./.config (This config was pulled from SuperRAM 1.5's /proc/config.gz)
# make CROSS_COMPILE=/files/Software/Android/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi- ARCH=arm menuconfig
# make CROSS_COMPILE=/files/Software/Android/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi- ARCH=arm zImage -j 4
arch/arm/mach-msm/built-in.o: In function `dex_cb_interrupt':
/files/Software/Android/hastarin/source/a/arch/arm/mach-msm/dex_comm.c:248: undefined reference to `notify_vbus_change_intr'
make: *** [.tmp_vmlinux1] Error 1
Click to expand...
Click to collapse
Any additional help would be appreciated. Also, is there a reason (performance, size, etc) CIFS is not included by default? I've noticed a lot of other builds are like that, too.
*EDIT* Is it possible I need to checkout a specific version of Hastarin's kernel?
Thanks,
B.

I posted this in the main thread before it was closed -
insmod: init_module 'cifs.ko' failed (Exec format error)
and I looked in dmesg -
cifs: version magic '2.6.32.15r8.6-gb02686c preempt mod_unload ARMv7' should be '2.6.32.15-g2ef5752.dirty preempt mod_unload ARMv7'
Looks like this might be a side effect of the custom kernel and the magic not matching up with the cifs.ko from hastarin. Could this be recompiled with the correct kernel?
Looks like the cifs.ko that was included in the build was the stock module from hastarin - so when you do recompile it, could you post the module as well? I'd love to help, but I don't have a whole lot of experience with compiling kernels.
Thanks.

indecided said:
I posted this in the main thread before it was closed -
insmod: init_module 'cifs.ko' failed (Exec format error)
and I looked in dmesg -
cifs: version magic '2.6.32.15r8.6-gb02686c preempt mod_unload ARMv7' should be '2.6.32.15-g2ef5752.dirty preempt mod_unload ARMv7'
Looks like this might be a side effect of the custom kernel and the magic not matching up with the cifs.ko from hastarin. Could this be recompiled with the correct kernel?
Looks like the cifs.ko that was included in the build was the stock module from hastarin - so when you do recompile it, could you post the module as well? I'd love to help, but I don't have a whole lot of experience with compiling kernels.
Thanks.
Click to expand...
Click to collapse
Hi indecided,
This is the post I'm looking to resolve for everyone. Once I figure this out, I'll post how to patch the SuperRAM 1.5 to support CIFS.
Thanks,
B.

this is great news and i'm looking forward to this - i hope your efforts can accomplish this - it probably won't be easy, which is why hastarin and darkstone might have needed to focus their efforts on other things first -- i'm not being negative, i'm just saying that if you guys get this to work it might be an impressive thing you did. I need it bad too.

OK, unfortunately I've hit a bit of a roadblock. I've got the kernel to compile using nearly all the same config settings as DarkStone with CIFS added, but upon booting the kernel the phone acts as if there is 0% battery and instantly shuts itself off. I'm guessing it has to do with the one problem I had in compiling explained below.
The only difference in the configs for compiling were (removed CIFS info):
# diff MY.config DARKSTONES.config
119,120c119
< CONFIG_SLOW_WORK=y
< # CONFIG_SLOW_WORK_DEBUG is not set
---
> # CONFIG_SLOW_WORK is not set
241,242c240
< CONFIG_HTC_BATTCHG=y
< # CONFIG_HTC_BATTCHG_SMEM is not set
---
> # CONFIG_HTC_BATTCHG is not set
Click to expand...
Click to collapse
So basically, DarkStone's version had SLOW_WORK and HTC_BATTCHG disabled. I have no idea how he accomplished this. No matter what I set SLOW_WORK to, the compilation always changes it back. And if I try to disable HTC_BATTCHG, the kernel errors out with the message from my previous posts.
I'm also not entirely sure the patch DarkStone posted is complete (unless he responds otherwise) because it does end prematurely and was perhaps cut off by pastebin.
I wish I knew what else to try, but I'm not knowledgable enough to know why it thinks the battery is at 0%. I'm guessing it has something to do with the BATTCHG config, but I have no way around it at the moment.
Thanks,
B.

sorry to disturb here, but if you where to successfully recompile, what will be the benefit?
thanks you

there should be tons of warnings though correct?

Fmstrat said:
Any additional help would be appreciated. Also, is there a reason (performance, size, etc) CIFS is not included by default? I've noticed a lot of other builds are like that, too.
*EDIT* Is it possible I need to checkout a specific version of Hastarin's kernel?
Thanks,
B.
Click to expand...
Click to collapse
Hi! Sorry to hear you're having issues with building the kernel.
Here is a properly formatted patch that I've made: http://www.multiupload.com/FDJ4FXZ4L9
I used the eb_oldcam branch (or was it oldcam_eb? I've forgotten )
Try using the htcleo_hastarinconfig as the defconfig file.
I recommended that toolchain because Hastarin and myself have experienced issues with other toolchains causing the proximity/light sensor to eat up more battery during standby.
Hope this helps!
-------
Oh and Merry Christmas folks!

dapoharoun said:
sorry to disturb here, but if you where to successfully recompile, what will be the benefit?
thanks you
Click to expand...
Click to collapse
Ability to mount shares computers over wifi for playing media.

Fmstrat said:
Ability to mount shares computers over wifi for playing media.
Click to expand...
Click to collapse
It's like having a 4 terabyte sdcard. If you have say a 30,000 song collection, and you connect to your home computer via wifi at home you click the songs and they play instantly. For me, I click any one of my 3000 movies and they play on my hd2 in 10 seconds, and I can fast forward and rewind almost instantly.
If you are on the road and have a vpn to your computer and you 'mount the home share remotely' you now have a "virtual sd card" with 30,000 songs that play when you click the songs after about a 6 second lag.

DarkStone1337 said:
Hi! Sorry to hear you're having issues with building the kernel.
Here is a properly formatted patch that I've made: http://www.multiupload.com/FDJ4FXZ4L9
I used the eb_oldcam branch (or was it oldcam_eb? I've forgotten )
Try using the htcleo_hastarinconfig as the defconfig file.
I recommended that toolchain because Hastarin and myself have experienced issues with other toolchains causing the proximity/light sensor to eat up more battery during standby.
Hope this helps!
-------
Oh and Merry Christmas folks!
Click to expand...
Click to collapse
Good news everyone. It's working.
Thanks DarkStone for all your input, using the default config and eb_oldcam worked with the new patch you provided on the first try this time (Btw, I am using the toolchain you recommended now). I do have one last question though, how do I get it to load cifs.ko on boot? Android doesn't appear to have any modprobe.conf or anything similar that I see, so I must be missing something. I have to insmod it manually right now.
*EDIT*: I ended up rebuilding it directly into the kernel instead of a module for now, which works. I know that's not "proper" but that will ensure CIFS is always loaded even if the build doesn't load it by default. If you know a better way, I'm all ears Thanks again! */EDIT*
For everyone else, this is not an EXACT copy of the SuperRAM kernel that DarkStone used, but it's pretty close and seems to be the config they recommend going forward. Rather than post it here right now, I'll give it out as a Christmas gift later today in the Development forum since it will really apply to any RAM release going forward that uses Hastarin's kernel and post a link here. This will give me some time to test and ensure nothing goes weird.
Thanks,
B.

OK, it's all done: Download, installation instructions, and FAQ
I've also opened a thread back in the Android Development section since this is no longer a Q&A: http://forum.xda-developers.com/showthread.php?t=887567
Thanks,
B.

[SCRIPT] A Handy Script to build CyanogenMod from source: "It does stuff" [v0.2]

[SCRIPT] A Handy Script to build CyanogenMod from source: "It does stuff" [v0.2]
I know everyone's probably like, hey, since CM is officially released, why do we need this? I'll tell you why. You know how all of the other phones get nightlies? I feel left out. That's why I've created this handy script to walk you through everything from getting source to building and eventually flashing. The script will be updated somewhat frequently as I add features and such. To start off, I'll walk you through how to use it. There are several switches that you can use, such as setup, init, clean, or dirty. Setup will do the initial setup for you, installing packages and repo and rebooting your computer. Init will initialize the CyanogenMod repository on your computer. Clean will build with a "make clean" to be sure everything is fresh. Dirty will, you guessed it, build what I consider a "dirty" build, with no make clean. Much faster, but more prone to glitches. Usage is simply cd'ing to where you saved the file, possibly chmod a+x'ing it (I'm not sure if mediafire retains the permissions set on a file locally), and then running ./buildscript.sh your_option_here. (Example:
Code:
./buildscript.sh clean
will clean your repositories and build from scratch.) Thats it! Have fun, and be safe.
*I am not responsible for any damages, emotional harm, dead puppies or goldfish caused by using this script.
Download: HERE
Come here to report issues, glitches, and/or enhancements.
https://github.com/ytt3r/buildscripts/issues

v0.3(Coming Soon)
Fixed running the radio script
A few minor changes
More aesthetic changes
v0.2
Added an option not to reboot on setup of repo
Aesthetic changes
Added copying of modules to the correct locations
Other stuff I can't remember (maybe, I'm too lazy to diff) lol
v0.1
Initial script: enables users to do several things very easily

You're just trying to make me boot into Linux more often, aren't you? I will definitely be taking advantage of this.
Sent from my CM7 powered captivate

Brilliant.

I still haven't synced the repo, I started to but it ate up so much bandwidth on my network.

This'll do it for you
Sent from my Captivate using XDA App

I am wondering if you can give the exact process we need to run this script in and what os it supports.
Currently trying to run it on an ubuntu install and having some problems. I run setup and it eventually asks to reboot and continue the script, i hit yes and it exits the script. nothing more. I reboot and then try to do the script with init but complains about missing directories.
found some errors when doing setup
E: Unable to locate package lib32z1-dev
E: Unable to locate package lib32ncurses5-dev
E: Unable to locate package lib32readline5-dev
./buildcaptivate.sh: line 22: curl: command not found
Click to expand...
Click to collapse

Are you on a 64 bit system?
Sent from my Captivate using XDA App

ytt3r said:
Are you on a 64 bit system?
Sent from my Captivate using XDA App
Click to expand...
Click to collapse
Its in vmware an very well could be 64-bit, or 32-bit.
looked it up and its 32-bit i guess.
Is the script for only 64-bit?

for the sake of learning something, could i get a laymans explanation of what this does?
or am i on the right track by...
it builds a captivate CM rom from (Android? not samsung) source?

ccdoggy said:
Its in vmware an very well could be 64-bit, or 32-bit.
looked it up and its 32-bit i guess.
Is the script for only 64-bit?
Click to expand...
Click to collapse
Only runs on a 64 bit system.
Trusselo said:
for the sake of learning something, could i get a laymans explanation of what this does?
or am i on the right track by...
it builds a captivate CM rom from (Android? not samsung) source?
Click to expand...
Click to collapse
You can run it every night by saying something like
Code:
./buildcaptivate.sh clean
which will build CyanogenMod clean for you, as an unofficial self-built nightly.

Do Not Run Current Version
This script makes some alarming system-wide changes:
Code:
sudo rm /bin/sh
sudo ln -s /bin/bash /bin/sh
and that's just in the first few lines, I haven't even read through the rest of the way through the script yet.
y3ttr, you need to go through this script and find ways of doing this with less system wide impact, and you need to spell out in the OP exactly what system changes are still made (the new apt repositories, for instance, which is a system change you likely won't be able to get around, for instance). Also, I recommend having stuff like the source location and stuff to be a variable that can be changed (for instance, lots of people would prefer to keep source in /usr/src, etc).
Another option you could look into is using a chroot jail for a lot of the build process, so you don't impact the wider system. Also, add some if/else statements so that this can run on something other than Ubuntu 64bit. Shouldn't be that hard.
Edit: i've read through some more of the script, here are some more thoughts:
no need to reboot, use source ~/.bashrc. But even for that, you shouldn't be adding stuff to a users' PATH permanently. Just do it in the script leave it at that.
to make it i386 or x64 compatible, use a uname -p to determine the arch type and a switch statement
do not change the default shell. there should be no need.
too many hard coded paths. use some variables, $PWD, and which to figure out locations and paths.
to make this really cool, have an option to automatically copy it to /usr/local/bin and have it run from cron every night.
have an variable to set where the build root is located, and another one to set where the final builds will be dumped (for instance: build in /usr/src, but place the final builds in ~/cyanogenmod/).

DamnMersault said:
This script makes some alarming system-wide changes:
Code:
sudo rm /bin/sh
sudo ln -s /bin/bash /bin/sh
and that's just in the first few lines, I haven't even read through the rest of the way through the script yet.
y3ttr, you need to go through this script and find ways of doing this with less system wide impact, and you need to spell out in the OP exactly what system changes are still made (the new apt repositories, for instance, which is a system change you likely won't be able to get around, for instance). Also, I recommend having stuff like the source location and stuff to be a variable that can be changed (for instance, lots of people would prefer to keep source in /usr/src, etc).
Another option you could look into is using a chroot jail for a lot of the build process, so you don't impact the wider system. Also, add some if/else statements so that this can run on something other than Ubuntu 64bit. Shouldn't be that hard.
Click to expand...
Click to collapse
This removal of sh is required as ubuntu defaults to using dash for some god-forsaken reason instead of bash. so the symlink must be placed in (most people won't even notice a difference for the remainder of their ubuntu lifespans) to guarantee that bash is used for all the building process (as it's required).
also, this isn't meant to truly be "configurable" as you're describing, it's merely meant to be simple/easy for people to build their own nightly (at their own risk)

Kaik541 said:
This removal of sh is required as ubuntu defaults to using dash for some god-forsaken reason instead of bash. so the symlink must be placed in (most people won't even notice a difference for the remainder of their ubuntu lifespans) to guarantee that bash is used for all the building process (as it's required).
also, this isn't meant to truly be "configurable" as you're describing, it's merely meant to be simple/easy for people to build their own nightly (at their own risk)
Click to expand...
Click to collapse
If the build process requires bash, then the build scripts should specify #!/bin/bash, not #!/bin/sh.

E: Unable to locate package lib32z1-dev
E: Unable to locate package lib32ncurses5-dev
E: Unable to locate package lib32readline5-dev
Click to expand...
Click to collapse
I believe are
lib64z1-dev
libncurses5-dev
libreadline5-dev
on a 32bit system. At least from what I gathered reading a CM forum post.
Hopefully that will save a little bit of time for anyone trying to build on 32bit, there are some extra steps once you start compiling, but I still haven't been able to to figure out why I'm getting fatal errors during the syncing/download process. So I have no idea if the workarounds for a 32bit system work for CM7 during the build process.
Here is the CM thread, post #21. Link.

ytt3r, regarding your script...
It does stuff !

Truly priceless quote.
Sent from my SAMSUNG-SGH-I897 using XDA App

Thank you for this! It seems to be working... I don't know if it's the repo or my ubuntu acting weird....
Kernel don't want to build (either manually or with this)
But I was able to do it 2 days ago with the same computer.! Will try again later.

[ee03] add init.d support

I managed to get init.d working on the EE03 leak but it broke logcat, I switched to the no-op scheduler and it seems to be quite a bit more responsive =p
I wish I could post how I did it but xda thinks a file path is an outside link and wont let me submit it...
Is this useful at all? I don't know much about android but I'm a linux nerd by profession

chairface said:
I managed to get init.d working on the EE03 leak but it broke logcat, I switched to the no-op scheduler and it seems to be quite a bit more responsive =p
I wish I could post how I did it but xda thinks a file path is an outside link and wont let me submit it...
Is this useful at all? I don't know much about android but I'm a linux nerd by profession
Click to expand...
Click to collapse
Makes sense that noop i/o would be more responsive as it's designed for flash memory devices. Init.d is supported by default in cm7 and it's always handy to have it around for keeping things out of the original init.<device>.rc without having to recompile initramfs.
All you need is 10 posts and you'll be able to post whatever you need.
You can also use the 'CODE' tags to paste paths, etc.

init.d was enabled via the initramfs in the kernel. Scrips go in /system/etc/init.d - and have on every ROM with initscripts enabled.
Thanks for the tip on the scheduler - feel free to play around with the other settings. Have a look at the tweaks thread for some possibilities.

k0nane said:
init.d was enabled via the initramfs in the kernel. Scrips go in /system/etc/init.d - and have on every ROM with initscripts enabled.
Thanks for the tip on the scheduler - feel free to play around with the other settings. Have a look at the tweaks thread for some possibilities.
Click to expand...
Click to collapse
/system/bin/sh can't parse if [ <x> ] statements...
the block in twilightzone.sh that says
<code>
if [ -d /etc/init.d ]
then
run-parts /etc/init.d
fi
</code>
should be changed to
<code>
/sbin/busybox [ -d /etc/init.d ] && /sbin/busybox run-parts /etc/init.d
</code>
thanks for all your hard work man
also the updater-script has to set everything in /etc/init.d to 755 - it doesn't in ee03

I wasn't aware init.d support was there until after I wrote the script.

oh haha
I changed /system/bin/sh to point to busybox... the only thing it seems to break is logcat =\
before I did this nothing in /etc/init.d worked, if I did
/sbin/twilightzone.sh
it wouldn't run /etc/init.d but if I did busybox sh /sbin/twilightzone.sh it did
I probably broke a lot of other stuff doing this too but it's working well so far.
while I have someone knowledgeable here, is it possible to extract/repack the zImage? I'm assuming either ACS did that or used an older 2.2 kernel

[Kernel] Tweaked Boog KH3 Captivate

New!!! -- BETA! BETA! BETA!-- UCKI1 kernel with Voodoo lagfix!
See this thread....
======================================
Mod_Boog_KH3_kernel_V3_V1
Thanks to Boog for a great kernel! I took it apart and tweaked it a bit mainly so that I would have full functionality in ADB and DDMS.
default.prop
Changed the following to allow ADB / DDMS to run as root:
ro.secure=0
ro.allow.mock.location=1
ro.debuggable=1
persist.service.adb.enable=1
init.rc
Modified to execute /system/etc/init.d scripts at boot. Also added sysctl.conf to /system/etc.
more...
Symlinks from Busybox to "ls" and "ps" have been removed from /sbin so that DDMS will work correctly. They now fall back to Toolbox links in /system/bin.
Several scripts have been added to /system/etc/init.d for experimenting. They can be removed, modified and added to as desired. However, the script "S99complete" should remain intact... without it NO scripts will be executed.
Have fun!
DOWNLOAD HERE

> Modified to execute /system/etc/init.d scripts at boot. Also added sysctl.conf to /system/etc.
How did you done that?
If /etc/init.d can be runned - can we have a mount commands changed to ext4?

Yuna said:
> Modified to execute /system/etc/init.d scripts at boot. Also added sysctl.conf to /system/etc.
How did you done that?
If /etc/init.d can be runned - can we have a mount commands changed to ext4?
Click to expand...
Click to collapse
I'll post the relevant parts of init.rc tomorrow... it's 2 am here and I'm going to bed! As for changing the mounts to ext4, there probably is a way but I'm not sure I want to be in the kernel / rom business. I just needed to fix ADB / DDMS and got a bit carried away.

by asking "how did you done that" i mean - how did you managed to change init.rc in pre-compiled kernel?

Yuna said:
by asking "how did you done that" i mean - how did you managed to change init.rc in pre-compiled kernel?
Click to expand...
Click to collapse
I extracted the ram disk with a script... I'll post that tomorrow also.

Yuna said:
by asking "how did you done that" i mean - how did you managed to change init.rc in pre-compiled kernel?
Click to expand...
Click to collapse
Get the extraction scripts here:
http://forum.xda-developers.com/showthread.php?t=901152
repackImage.sh has a bug though...
search for and change:
local at_min=
to
local at_min=0

Thanks.. I will give it a try. Good job and good luck for future work.

mtcarey said:
Mod_Boog_KH3_kernel_V3_V1
Thanks to Boog for a great kernel! I took it apart and tweaked it a bit mainly so that I would have full functionality in ADB and DDMS.
default.prop
Changed the following to allow ADB / DDMS to run as root:
ro.secure=0
ro.allow.mock.location=1
ro.debuggable=1
persist.service.adb.enable=1
init.rc
Modified to execute /system/etc/init.d scripts at boot. Also added sysctl.conf to /system/etc.
more...
Symlinks from Busybox to "ls" and "ps" have been removed from /sbin so that DDMS will work correctly. They now fall back to Toolbox links in /system/bin.
Several scripts have been added to /system/etc/init.d for experimenting. They can be removed, modified and added to as desired. However, the script "S99complete" should remain intact... without it NO scripts will be executed.
Have fun!
DOWNLOAD HERE
Click to expand...
Click to collapse
good job as a dev adbd as root is mandatory
ki2 is out what are you waiting for ?

mtcarey said:
Mod_Boog_KH3_kernel_V3_V1
Thanks to Boog for a great kernel! I took it apart and tweaked it a bit mainly so that I would have full functionality in ADB and DDMS.
default.prop
Changed the following to allow ADB / DDMS to run as root:
ro.secure=0
ro.allow.mock.location=1
ro.debuggable=1
persist.service.adb.enable=1
init.rc
Modified to execute /system/etc/init.d scripts at boot. Also added sysctl.conf to /system/etc.
more...
Symlinks from Busybox to "ls" and "ps" have been removed from /sbin so that DDMS will work correctly. They now fall back to Toolbox links in /system/bin.
Several scripts have been added to /system/etc/init.d for experimenting. They can be removed, modified and added to as desired. However, the script "S99complete" should remain intact... without it NO scripts will be executed.
Have fun!
DOWNLOAD HERE
Click to expand...
Click to collapse
Awesome! This is what I was looking for! Was hoping that someone with a bit more knowledge would chime in on some of this stuff.
I am super new to tweaking all that stuff, I'll look into your changes, and could roll them back over into mine, and future releases. All the fun stuff is coming out while I am at work!

boog said:
Awesome! This is what I was looking for! Was hoping that someone with a bit more knowledge would chime in on some of this stuff.
I am super new to tweaking all that stuff, I'll look into your changes, and could roll them back over into mine, and future releases. All the fun stuff is coming out while I am at work!
Click to expand...
Click to collapse
Have at it boog! I didn't really know these changes off the top of my head... had to dig around a bit. I'll post the change to init.rc soon for the init.d stuff.

DAGr8 said:
good job as a dev adbd as root is mandatory
ki2 is out what are you waiting for ?
Click to expand...
Click to collapse
I'll leave ki2 to boog... got my hands full with app development!

Modification of init.rc to run init.d scripts at boot
# ============================================== MTC
setprop cm.filesystem.ready 0
start sysinit
on property:cm.filesystem.ready=1
### Script S99complete in init.d sets this property to 1 and
### allows processing to continue. Do not remove this script!!!
# ==================================================
class_start default
## Daemon processes to be run by init.
##
# Declaration of service to execute scripts in /etc/init.d ===== MTC
service sysinit /sbin/run-parts /system/etc/init.d
disabled
oneshot
# =================================================

Mtcarey, if you could get EXT4 support on this kernel you would be a God!!!
Sent from my SAMSUNG-SGH-I897 using xda premium

amwbt said:
Mtcarey, if you could get EXT4 support on this kernel you would be a God!!!
Sent from my SAMSUNG-SGH-I897 using xda premium
Click to expand...
Click to collapse
Funny you should mention that.... I was just just looking into it.

mtcarey said:
Funny you should mention that.... I was just just looking into it.
Click to expand...
Click to collapse
Please do! Since designgears left the Captivate, no one cares to keep up the work. In my opinion, the Captivate is useless without it. I just can't bring myself to run a Captivate rom without EXT4 support.
Sent from my SGH-I897 using xda premium

amwbt said:
Please do! Since designgears left the Captivate, no one cares to keep up the work. In my opinion, the Captivate is useless without it. I just can't bring myself to run a Captivate rom without EXT4 support.
Sent from my SGH-I897 using xda premium
Click to expand...
Click to collapse
The latest builds fly without ext4. Not sure I would call it useless.
But, I ended up getting into the kernel stuff because it appeared no one else was going to.

boog said:
The latest builds fly without ext4. Not sure I would call it useless.
But, I ended up getting into the kernel stuff because it appeared no one else was going to.
Click to expand...
Click to collapse
I agree with you, ki2 is super fast and stable (with no ext4)

mtcarey said:
Funny you should mention that.... I was just just looking into it.
Click to expand...
Click to collapse
If you do find something, I would be curious to know. Everything I have tried (pulling lagfix out of other kernels) results in initramfs being too large. Even after removing all the voices.
I'm just not sure how much gain would be had for all the work. Getting sources would be cool.

boog said:
If you do find something, I would be curious to know. Everything I have tried (pulling lagfix out of other kernels) results in initramfs being too large. Even after removing all the voices.
I'm just not sure how much gain would be had for all the work. Getting sources would be cool.
Click to expand...
Click to collapse
Yup. Exactly what happened to me. I tried everything to get the size down, but still ended up about 1 mb too big. Oh well, it was a learning experience. I agree that there probably isn't much to gain anyway... rfs now seems as fast as ext4 ever was.

Why don't you make your own lagfix? e.g why need to put all the voodoo stuff, if you (IMHO) need to edit init.rc mount stuff:
mount rfs /dev/block/mmcblk0p2 /data nosuid nodev crypt check=no
mount rfs /dev/block/stl10 /dbdata nosuid nodev crypt check=no
Why not to try this way?
Well, voodoo by itself is good cos it auto-converts partitions - but sometimes it lags
but why not to do this, and after time make a auto-conversion script?

[B928] OC kernel 0.1 [one-hit wonder]

This will not be worked on any longer thanks to Huawei's incompetence. I'm glad my main phone isn't by them. I leave my 0.2 diff attached (which did make my phone faster FWIW - and has fsync() control. Not of use to me, but people who use a modified libsqlite would like it...). Feel free to apply it and see if you can somehow fix dhd.ko loading.
Hi,
Not one for names, so this shall be known as "OC kernel" This is built from the ICS U8800pro source that Huawei put out.
Install at your own risk; I take no responsibilty for any damage that may occur through the usage of this kernel.
Features:
ADB as root
Overclocking enabled (thanks to genokolar)
Undervolting interface added (from genokolar, who took it from a SE kernel modder somewhere) - I think SetXperia can use it
SIO I/O scheduler added
SmartassV2 cpufreq scheduler (AnDyX mod) - although I think ondemand does a bit better IMO
sysfs entry to turn off keypad lights (I wrote an applet for this some time back, I'll dig it out later)
Logcat is always enabled now as the ServiceMenu toggle doesn't work anymore
Minimum display backlight is set to 15, but I think Android needs a framework change to use it. You could try RootDim
Kernel actually builds (and Bluetooth works)
ZRAM (+ swap) support. ZRAM is optimized for Android (taken from Siyah kernel). I'll write up the instructions on enabling this later
CIFS as module
Extras:
Change schedulers and phone speed:
Use a tool like No Frills CPU or SetCPU.
Turn off button lights:
Install the ButtonLight widget and add it to your main screen. I've published the source before in another thread; seek it out if you're after its (bad) code.
It's buggy the first few times you run it, but works fine after that.
Dim screen to 14:
The minimum backlight level is now set to 15. RootDim from the Play Store lets you set it to that.
Mount Windows shares:
Grab CifsMounter and point it to the cifs.ko in /system/lib/modules. You may also need to insmod nls_utf8.ko and md4.ko.
Enable ZRAM (taken from Siyah kernel):
(Note I've not used ZRAM so I have nothing to say on its stability, good or bad)
Grab a BusyBox binary from somewhere
Run the following commands:
Code:
echo 90 > /proc/sys/vm/swappiness #You must set the swappiness high to ensure that the compressed RAM is accessed first!
echo $SIZE > /sys/devices/virtual/block/zram0/disksize #Set size to whatever you wish. 100MB is 104857600 = 100 * 1024 * 1024
busybox mkswap /dev/block/zram0
busybox swapon /dev/block/zram0
Dump the lines in install-recovery.sh if you want to be ZRAMMed every time you boot the phone (although in that case, make sure you have
Code:
busybox swapoff /dev/block/zram0 > /dev/null 2>&1 #Use > /dev/null 2>&1 for every busybox command in install-recovery.sh as it will discard any messages outputted
echo 1 > /sys/devices/virtual/block/zram0/reset
before the lines above)
Install:
Flash the attached ZIP in CWM recovery. You should backup your original boot.img and /system/lib/modules first
Source:
Take http://www.huaweidevice.com/worldwi...=toDownloadFile&flay=software&softid=NDY3NTU= and apply attached diff

at last..xaaxxaa!!but why with modules too???whats their use?

pikachukaki said:
at last..xaaxxaa!!but why with modules too???whats their use?
Click to expand...
Click to collapse
'cause I add a new module - cifs (used by CifsMounter if you want to mount Windows shares) - and because the modules that are originally in /system/lib/modules need to be replaced so that they can load with this kernel (I don't know what those modules do, but I'd rather play it safe)

qwerty12 said:
'cause I add a new module - cifs (used by CifsMounter if you want to mount Windows shares) - and because the modules that are originally in /system/lib/modules need to be replaced so that they can load with this kernel (I don't know what those modules do, but I'd rather play it safe)
Click to expand...
Click to collapse
Boot normally change io to sio and smartassv2...1500mhz lets check..good work..i envy you and i want your guide on compiling...xaaxax im off to bed!!
fps is locked!!xaaxax

pikachukaki said:
Boot normally change io to sio and smartassv2...1500mhz lets check..good work..i envy you and i want your guide on compiling...xaaxax im off to bed!!
fps is locked!!xaaxax
Click to expand...
Click to collapse
I'll write it up sometime - but bear in mind I'm not an expert at this
Regarding FPS: do the install-recovery.sh trick
Only thing I modify in initramfs is the ro.secure setting so that ADB can be ran as root

qwerty12 said:
I'll write it up sometime - but bear in mind I'm not an expert at this
Regarding FPS: do the install-recovery.sh trick
Only thing I modify in initramfs is the ro.secure setting so that ADB can be ran as root
Click to expand...
Click to collapse
You did a great job i couldnt even compile the kernel without changes!!you did great!!
the difference is obvious !!
Sent from my U8800Pro using xda premium

Pika When U add This Kernet To ur ROM?

As expected from qwerty12!
Great job!
I'll also request a guide on how to build the kernel like pika asked.
Hope you continue to improve the kernel! A thanks is simply not enough to thank you for your work, but thanks again

husen4u said:
Pika When U add This Kernet To ur ROM?
Click to expand...
Click to collapse
I wont!just d/w it and flash it!simple!
Sent from my U8800Pro using xda premium

Now what you suggest oc ics or kalo gb?
Sent from my U8800pro using xda app-developers app

husen4u said:
Now what you suggest oc ics or kalo gb?
Sent from my U8800pro using xda app-developers app
Click to expand...
Click to collapse
From now on i wont ever go back to GB ever again! if our luck changes and someone release cm9 i will forget what gb is!! there are some small bugs but the rom is usable for everyday!!

Moihack said:
As expected from qwerty12!
Great job!
Click to expand...
Click to collapse
Thank you
I'll also request a guide on how to build the kernel like pika asked.
Click to expand...
Click to collapse
Certainly, sir.
Hope you continue to improve the kernel! A thanks is simply not enough to thank you for your work, but thanks again
Click to expand...
Click to collapse
Unfortunately I won't be working on this anymore unless Huawei get back to my request for the source to the the dhd.ko module (which they may not have to comply with because the license for the module states "Unless you and Broadcom execute a separate written software license agreement governing use of this software" so the U8800pro version may not be under GPL). I made (well, found on the Internet) more optimizations but the Wi-Fi refuses to turn on because the dhd.ko module refuses to load. Only way I can get something working is to build the source that Huawei give or attempt to force other versions of the bcm source to load, but it's unlikely that would work.
--
Anyway, a small guide.
I used an x86_64 laptop running (X)ubuntu 12.04.1 to follow these steps. This page was a great resource.
Prerequisites:
A computer running GNU/Linux (a Mac should work in theory - the same toolchain we use is built for it, too, but I have no idea how OS X works)
git installed (apt-get install --no-install-recommends git-core is enough under Ubuntu)
sudo apt-get install flex bison gperf build-essential libncurses5-dev zlib1g-dev ia32-libs lib32z1-dev lib32ncurses5-dev gcc-multilib g++-multilib abootimg
Getting ADB working
One of the best things to do is getting ADB set up, as you then have easy communication with the device. It's not essential but you'll just end up wasting time transferring files through other, longer means.
Grab the Linux platform tools ZIP from here: http://www.hariadi.org/android/manually-download-of-android-sdk-tools-and-sdk-platform-tools/. Extract the adb binary from the zip file, preferably to somewhere in your $PATH. chmod 755 it. chown, if necessary.
Next, open http://aur.archlinux.org/packages/an/android-udev/android-udev.tar.gz and, doing all this as root (sudo in Terminal etc.), place 51-android.rules in /lib/udev/rules.d/ (not the best place - but it works), chmod 644 it and chown root:root it.
Next, execute /usr/sbin/groupadd adbusers, followed by gpasswd -a USERNAME adbusers, USERNAME being the user you normally log on with.
Restart (while you can force Linux to see the new group through the, well, newgrp command udev will not "see" the new rule, despite how much you try with udevadm).
That should be ADB set up (give it a test, remembering to enable USB debugging mode on the phone first!).
On to preparing your workarea.
--
Create a new folder in your home folder and cd to it. This folder will house the prebuilt folder of toolchains and other stuff, and the kernel source in a folder of its own.
In this folder, execute git clone --depth 1 https://android.googlesource.com/platform/prebuilt.git and move onto the next step, since the download takes a while. That command grabs the prebuilt toolchain from Google using Git, but doesn't obtain a deep history for each file to make the download quicker.
Open http://www.huaweidevice.com/worldwi...=toDownloadFile&flay=software&softid=NDY3NTU= and save the source to your Downloads directory. After git has finished running, still in the folder with the "prebuilt" folder, execute tar jxf ~/Downloads/HUAWEI_U8800pro<tab - as in actually press tab> and you should have a kernel folder alongside the prebuilt one.
Building the kernel
cd to this new kernel folder.
First things first: make sure that Bluetooth is properly enabled by editing the Makefile. Find the line #ifeq ($(ENABLE_BTLA_VER30),true) and comment out every line in that section except for KBUILD_CFLAGS += -DHUAWEI_BT_BTLA_VER30 so you end up with this:
Code:
#/* < DTS2012020604357 zhangyun 20120206 begin */
# Add Huawei Marco for different BT chip
#ifeq ($(ENABLE_BTLA_VER30),true)
KBUILD_CFLAGS += -DHUAWEI_BT_BTLA_VER30
#endif
#ifeq ($(ENABLE_BLUEZ_VER30),true)
#KBUILD_CFLAGS += -DHUAWEI_BT_BLUEZ_VER30
#endif
#/* DTS2012020604357 zhangyun 20120206 end > */
Commenting out the offending code leaves you with a kernel that builds but a Bluetooth module that won't start up - the same also applies if you try to build with the other define.
You can also make things easier for yourself by replacing the following
Code:
ARCH ?= $(SUBARCH)
CROSS_COMPILE ?= $(CONFIG_CROSS_COMPILE:"%"=%)
with
Code:
ARCH ?= arm
CROSS_COMPILE ?= ../prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-
else you will have to put "ARCH=arm CROSS_COMPILE=../prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-" after "make" each time. Remember this as I'll be assuming that you went for the option to edit the Makefile. I also assume that the prebuilt folder is above the kernel one. Adjust CROSS_COMPILE if necessary.
The ARCH variable is self-explanatory, but the CROSS_COMPILE variable (and the toolchain that it's pointing to) need to be set because the standard GNU development tools that apt installs don't produce output that an ARM processor can understand. So you cross-compile: the tools are for the X86 architecture but produce ARM output. 4.4.3 is chosen because the stock kernel is compiled with GCC 4.4.3 (if you run "adb shell cat /proc/version" you'll see). The arm-eabi-4.4.3 folder is chosen over arm-linux-androideabi-4.4.x because it specifies that magic "3" (I know, bad way to decide but it works), and over i686-android-linux-4.4.3 because we don't want to produce code for the PC.
Get the current configuration in use by the stock kernel (as that's a good point to start from - a known working configuration): http://wiki.cyanogenmod.com/wiki/Building_Kernel_from_source#Configure_the_Build
I'd also recommend placing a copy of .config as arch/arm/configs/<your funky name here> so that if .config gets deleted (make clean etc.) you can run make <the name you gave to the file in arch/arm/configs> and have .config come back again.
(cp arch/arm/configs/<the name you gave to the file> .config if you didn't modify the Makefile to specify the ARM arch.)
Run make oldconfig (not always necessary - generally it's invoked if you've applied a patch that introduces a new config option and the option then needs to go into your .config. Run make menuconfig afterwards and customize away.
When you're done, run make -jX - X as in the number of cores you have + 1. So, in my case, with a quad-core processor and HyperThreading enabled on all of them, "make -j9" works for me. If the compile went OK, you'll be left with a message saying that arch/arm/boot/zImage is ready. If not, run "make" without the -jX argument and make should stop where the error occurs. Have fun fixing the error!
Assuming that you have a new, shiny zImage, it's now time to put it into your boot.img.
Updating your boot.img:
Google have tools for this purpose but I've never used them so I don't know how they work. abootimg works fine for this, however.
Pull the current boot.img off your phone: adb pull /.cust_backup/image/boot.img.. I'd recommend creating a backup somewhere.
Create a new directory to store the boot.img in on your computer and run abootimg -x boot.img (if you had fun enabling every option in the kernel, you'll see why I'm telling you to use the -x option first rather than directly use the -u option). Now run abootimg -u boot.img -k <path to your newly built zImage>.
If this succeeds, yay! If not and you're told it's too big for the boot image, then don't worry. Take the size it's saying that the zImage is and convert that number into hex. Edit bootimg.cfg and change the value of the bootsize setting into the number you just converted into hex. We'll now repack again, but this time running abootimg -u boot.img -f bootimg.cfg -k <path to your newly built zImage>. This should work.
Sending the boot.img to the phone
If your ADB is already running as root, you can do the following to upload the new bootimg:
Code:
adb shell mount -o remount,rw /.cust_backup
adb push boot.img /.cust_backup/image/
adb reboot
If not, just reboot into pink screen mode and copy and paste.
Check System Settings and the version number should've changed. Congratulations!
Extras
Installing the modules:
OK, so you decided to build parts of the kernel as a module and you want to actually, y'know, have the modules present on the device. After building the kernel, execute:
make INSTALL_MOD_STRIP=1 modules_install INSTALL_MOD_PATH=<any folder name here>
If you look in that folder, you'll find the modules neatly wrapped up in folders, along with other text files. These text files are useless on a stock ROM because there's no modprobe - you need BusyBox for that. And since we don't want to have them seperated in folders (this is how the stock kernel does it), the files would be wrong, anyway. If you want to use modprobe and have BusyBox installed, you can run depmod on the phone after transferring the modules.
To get the modules into one folder make the directory "modules" in a folder higher-up to where the modules are stored, and then run for i in `find . | grep ko`; do mv "$i" ../modules/; done to move them into that folder.
At this point, I'd just recommend using my OC_Kernel.zip and replacing the modules in that. Or you can adb push them over to the /system/lib/modules folder (after issuing an "adb remount" - assuming that ADB is running as root in the first place).
Making ADB run as root:
As root on your computer, (we want to preserve permissions) use abootimg to split the boot image and extract the contents of the initrd:
abootimg -x boot.img && mkdir newramdisk && cd newramdisk && zcat ../initrd.img | cpio -i --no-absolute-filenames (--no-absolute-filenames is important! I trashed a Ubuntu install by leaving it out - the initrd contains ARM binaries of core Linux programs and if the initrd.img contains an absolute path of "/" then these files will get placed in /)
Make any changes you desire to the initrd. To have adb run as root, just edit /default.prop and set ro.secure to 0. Make sure that the editor you used didn't leave any backup files.
When you're done, run find . -print | cpio -o -H newc | gzip -n -9 > ../initrd.img and this will put the modified initrd folder back into initrd.img.
After that run cd .. ; abootimg -u boot.img -r initrd.img to actually put the initrd.img back into the boot.img.
If you run into a space error, you can do one of three things:
if you only made a single change (like enabling ADB), check to see that there is no backup file (default.prop~) littered about
you can remove the lengthy comments and copyright notices from the files to make space
you can use the trick we used earlier with abootimg to increase the size number in bootimg.cfg for the initrd
Overclocking:
Just look at the acpuclock C file (and possibly relevant cpufreq changes - but I can't remember) in my "OC kernel" diff. Make sure that the option in the kernel config is selected to limit the speeds to the U8800pro's native 1GHz, otherwise the phone will boot at 2GHz!
Rebuilding the Wi-Fi module:
I hope to be able to write this one since it's apparently needed in some cases, but it depends on if Huawei come through

any idea about this error?
drivers/mfd/pmic8058.c:327: error: rtc_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:327: error: rtc_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:241: error: othc0_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:241: error: othc0_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:250: error: othc1_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:250: error: othc1_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:261: error: othc2_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:261: error: othc2_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:183: error: misc_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:183: error: misc_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:210: error: thermal_alarm_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:210: error: thermal_alarm_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:270: error: batt_alarm_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:270: error: batt_alarm_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:152: error: pm8058_charger_resources causes a section type conflict
drivers/mfd/pmic8058.c:152: error: pm8058_charger_resources causes a section type conflict

matteof93 said:
any idea about this error?
drivers/mfd/pmic8058.c:327: error: rtc_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:327: error: rtc_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:241: error: othc0_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:241: error: othc0_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:250: error: othc1_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:250: error: othc1_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:261: error: othc2_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:261: error: othc2_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:183: error: misc_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:183: error: misc_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:210: error: thermal_alarm_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:210: error: thermal_alarm_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:270: error: batt_alarm_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:270: error: batt_alarm_cell_resources causes a section type conflict
drivers/mfd/pmic8058.c:152: error: pm8058_charger_resources causes a section type conflict
drivers/mfd/pmic8058.c:152: error: pm8058_charger_resources causes a section type conflict
Click to expand...
Click to collapse
Honestly, I have no idea. What toolchain are you using and where was your .config obtained from? Even when the Bluetooth thing was giving me errors, I never once saw that

same toolchain you have used. i have tried with ubuntu 12.04 x64 and ubuntu 10.04 x86 but same problem.....i have obtained my config from my phone using adb command

matteof93 said:
same toolchain you have used. i have tried with ubuntu 12.04 x64 and ubuntu 10.04 x86 but same problem.....i have obtained my config from my phone using adb command
Click to expand...
Click to collapse
I don't know why the same toolchain works on my laptop but not yours :\
Someone with a similar problem (same?) solved it by using an older toolchain: http://forum.xda-developers.com/showpost.php?p=27294383&postcount=7157

thanks thanks thanks.....i saw that post this morning but i did not noticed the post with the solution
UPDATE: NOW KERNEL COMPILED CORRECTLY....this means that tomorrow i know what to do

ZRAM (+ swap) support. ZRAM is optimized for Android (taken from Siyah kernel). I'll write up the instructions on enabling this later
qwerty your owning us some instructions!!xaaxxa

pikachukaki said:
qwerty your owning us some instructions!!xaaxxa
Click to expand...
Click to collapse
Done, check the first post
I also won't be working on this. My email (which does clearly state what I want, even if it's long-winded):
Dear Sir/Madam,
I recently built a kernel for my U8800pro from your sources and it
works fine, except that the Wi-Fi will not start because the dhd.ko
module that comes with the B928 firmware refuses to load into my
modified kernel. After looking around, the bcm4329 source is what I
need to build (usually distributed outside of the kernel); however, it
seems that the U8800pro uses a customized version. After looking at
the strings of the dhd.ko on the B928 firmware, I have seen many
strings that are present in that dhd.ko binary do not appear in:
* bcm_4.218.248.6_7x25_wifi_driver.tar from the Huawei Device website,
despite it having the same version number
* the bcm4329 source in the Qualcomm CodeAurora Git repository
* the bcm4329 source on the NyVIDIA Tegra Git repository
Furthermore, the strings also do not appear in the ICS kernel nor the
Gingerbread one. I can only conclude that Huawei have their own
specialized version of the bcm4329 4.218.248.6 source for the U8800pro
that is distributed outside the kernel. I understand that Qualcomm
allow the option to let the vendor arrange to have the code
distributed under a different license provided that the vendor makes
an agreement beforehand with Qualcomm. Otherwise it becomes GPLed by
default. If Huawei chose to make an agreement, then I have no right to
ask. However, I believe it is still licensed under the GPL for two
reasons:
* Running modinfo on the dhd.ko from the B928 firmware says this:
"license: GPL v2
* Both bcm_4.218.248.6_7x25_wifi_driver.tar.gz and
[S7][SoftWare]S7_Broadcom_BCM4329_4.218.205.0_Open_Source are under
the GPL
I would like to request the source code, please, of the bcm4329
4.218.248.6 source that is modified for the U8800pro if the code is
under the GPL
Best regards
Click to expand...
Click to collapse
was met with the following generic response:
Dear Customer,
Thank you for contacting Huawei device.
This is our website link http://www.huaweidevice.com/worldwide/searchResult.
do?method=execute&searchString=U8800pro where you can download the secure
code for U8800pro to you.
Once again thank you for contacting Huawei device.
Best Regards.
Huawei Device Customer Care Team.
Click to expand...
Click to collapse
Since my U8800pro is not my main phone anymore, I do not have the energy to fight. Nor do I want to work on Huawei's kernel, where you have to be careful about what you change or the Wi-Fi module won't load (and Huawei won't give you the source - which they should do since I'm sure it's under GPL). matteof93 will most likely produce something better or when everyone starts producing their own kernels and make enough improvements to be hit with the same issue as I, they'll start to get more emails and listen

@qwerty at the last command it said that device is busy...also is there any way that you can make it for init.d so it will be easier??thx!!