[ee03] add init.d support - Epic 4G General

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

Related

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

[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?

[I9001] [SCRIPT] Zram script for arco's ICS build

Hello everybody,
I thought that ICS was a little bit slow on my SGS+ so I tried to tweak it.
This is when I came across the option compcache in the settings -> performance menu.
Only I found this option isn't w orking yet in arco's alpha 3 build, or isn't working anymore.
Either way I found out that zram0 is present on the device, so I created a little script with which you can set-up Zram.
Just put it somewhere you can browse to with Terminal Emulator.
Also make sure it's permissions are set to rwx-r-x-r-x.
After you set the permissions right, just execute with: ./zram start
Or if you want to stop the swapping again just give in ./zram stop
This is the code for the script:
#!/system/bin/sh
#
# Zram manager
# koudumrulez{at}gmail.com (PsychoGame)
case "$1" in
start)
echo 3 > /proc/sys/vm/drop_caches
echo 30 > /proc/sys/vm/swappiness
# get the amount of memory in the machine
mem_total_kb=$(grep MemTotal /proc/meminfo | grep -E -o '[[:digit:]]+')
mem_total=$((0,25 * mem_total_kb * 1024))
# initialize the devices
echo $((mem_total)) > /sys/block/zram0/disksize
# Creating swap filesystem
mkswap /dev/block/zram0
# Switch the swap on
swapon /dev/block/zram0
;;
stop)
# Switching off swap
swapoff /dev/block/zram0
;;
*)
echo "Usage: $0 {start|stop}"
esac
exit 0
You can just call the file zram, and then copy it on you're device for example you're SD.
I only used this script on ALPHA3 build. Maybe it works on others as well, but that's at you're own responsibility.
Greetings Psycho Game
Here I'am again.
There's been a little error from my side.
If you put this file on you're SD-Card you can't set the permissions right.
What I did was putting the file in /system/bin, so the full path would be /system/bin/zram.
I did this with ES File Manager, but you're free to use whatever file manager you like.
After this make sure the permissions are set to rwx-r-x-r-x in the file manager, or in the terminal you can do a "chmod 755 /system/bin/zram" without quotes.
The zram is now useable through executing the command: "/system/bin/zram start or stop".
You can also choose to mount the zram automatically with booting.
In this case you have to make a file called userinit.sh in the folder "/data/local/"
This file needs the following content:
#!/system/bin/sh
/system/bin/zram start
I also set the permissions of this file to 755 with "chmod 755 /data/local/userinit.sh" but I'm not sure if this is neccesary. Anyway it works.
Hopefully somebody can use this script as well. If you do, please leave a comment. Also if you have questions feel free to ask. I will keep an eye on this post.
And the question if this will work on Alpha 4, yes it does.
Greetings,
Psycho Game
Hi Psycho,
thanks for your effort.
I also saw that zRam is indeed not working on the latest Alpha 6 (i use the Galxy W / i8150 Build).
I had a look at your script and some other sources and enabled zRam on my deivce for testing purposes.
My conclucsion so far is, that there seems so be some major problem of interference with an other memory management policy.
Independent from the Size and Swapiness configuration - there is something going wrong hier i think
I watched the systems memory stats through proc/meminfo and free. Once the system is out of fresh memory, it begins swapping. zRam swap then getfs filled up quickly. Now the system gets extremely slow, i also had two restarts (likely in cause of some kernel panics from acute memory problems).
Will be difficult to track down the problem, my guessings so far:
- Interference with LMK, as it only indirectly knows about zRam
- Some kind of io block size might have been set to a bad value for the zram device
- CPU-load through compression simply much to high (unlikely, but have not checked it yet)
.. and plenty other possibilites
ATM, its definitely only a huge decrease in performance for me. What was your experience?
From the technical specs, i guess zRam should behave much better, so i really guess theres going something wrong.
Guess i found a possible reason for the bad performance.
I will write more details when i have the time to.
Just tried the above script on CM9 (build 0814) for Galaxy Exhibit 4G (a sister phone of Galaxy W as I understand it). I ran the script in the Terminal. Initially the performance became very bad after a period of time (especially after opened many apps). It almost looked like zRam made it worse once it got used for some storage amount. However, after I changed mem_total_kb from MemTotal to MemFree, and removed 0,15 for mem_total, the horrible slow down seemed to disappeared (even after I opened 5 apps at the same time).
any further refinements of this 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!!

[TOOL][BOOT SCRIPTS] bse

Hello, all!
I have recently built a tool that allows users to more efficiently create and run scripts on boot.
These can be python scripts if you have python installed to your system (No, SL4A won't work. At least, not without some work). Usually though, they are bash or sh scripts.
They can be used to do various things, such as fix permissions every reboot, or things such as record a log of the time of every time you boot up your device, or other cool things.
I am currently looking into getting python packed into a flashable zip (lots of more fun with python scripts like showing a toast notification on boot).
To use bse's scripts executing feature, you must place the script you wish to execute under /system/etc/startup. You don't need to worry about chmodding it, there is an init script that does that already. For reference purposes, I recommend you read the contents of that init script (it's in /system/etc/startup).
To clarify, anyone who wants to build an automated installer for this, distribute some scripts, or distribute any modification to be, you have my full permission as long as you provide a link to this thread.
DOWNLOAD
https://docs.google.com/file/d/0ByulRvn_lJmbbnRfMG82Mm9Pb3c/edit?usp=docslist_api
INSTALLATION
- Just flash the zip file in the recovery of your choice
If you have any questions, feel free to ask. I'm sorry, this was written when I was tired (Not the program, the post)
Sent from my Nexus 7 using Tapatalk
FAQ:
What does "bse" stand for?
If you were to run bse alone, you would see that it stands for "Boot Script Executer".
Is BSE open-sourced?
Almost. I lost the source code and I'm in the process of re-creating it from scratch.
Where is the open source repo?
It's at https://github.com/boot-script-executer. PM me with your Github email if you wish to contribute to BSE development or submit your bse scripts. (please tell me which one)
Sent from my Nexus 7 using Tapatalk
Can we have a github source of all the scripts so we can execute in the Roms and execute it in the android source
nice idea
how about adding in a log wrapper to forward all output to the logcat
note: this is untested, but it should work
Code:
function logger() {
# args:
# $1 = message - the message you want to show
# $2 = priority - optional, defaults to i. the priority you want to give the log message
export LOG="/system/bin/log"
tag="BSE_LOGGER"
message=${1}
priority="i"
if [[ $2 ]]
then
options="vdiwe"
if test "${options#*$2}" == "$options"
then
$LOG -p "e" -t "$tag" "invalid priority level: $2"
else
priority=$2
fi
fi
$LOG -p "$priority" -t "$tag" "$message"
}
examples:
Code:
logger "this is a random message"
# I/BSE_LOGGER(15836): this is a random message
logger "another random message" d
# D/BSE_LOGGER(17393): another random message
logger "this message should give an error" t
# E/BSE_LOGGER(17395): invalid priority level: t
# I/BSE_LOGGER(17396): this message should give an error
This is freaking awesome r3. Good job bro.
*Starts slow clapping. Waiting for other people to join in.* ☺
Sent from my SAMSUNG-SGH-I337 using XDA Premium 4 mobile app
cybojenix said:
nice idea
how about adding in a log wrapper to forward all output to the logcat
note: this is untested, but it should work
Code:
function logger() {
# args:
# $1 = message - the message you want to show
# $2 = priority - optional, defaults to i. the priority you want to give the log message
export LOG="/system/bin/log"
tag="BSE_LOGGER"
message=${1}
priority="i"
if [[ $2 ]]
then
options="vdiwe"
if test "${options#*$2}" == "$options"
then
$LOG -p "e" -t "$tag" "invalid priority level: $2"
else
priority=$2
fi
fi
$LOG -p "$priority" -t "$tag" "$message"
}
Click to expand...
Click to collapse
i like the thought of this!
this is realy cool,great idea and work,thanx man.
Sorry if this sounds like a stupid question, but what's the difference between using init.d and your tool or even using script manager to run scripts at boot?
Sent from my GT-P7500 using Tapatalk
Hehe. Funny story about this. All of its source code (There wasn't too much... Don't worry) was on my trusty (not really) old Kindle Fire HD, which I managed to brick. I will have to re-write the source (Again, I didn't really lose that much) and I'll make everything open-sourced (see 2nd post if you want to help contribute).
cybojenix said:
nice idea ...
Click to expand...
Click to collapse
Thanks... I will try to see if I can implement that. If I have no sucess, you could try for yourself once I get everything re-written.
eushaun99 said:
Sorry if this sounds like a stupid question, but what's the difference between using init.d and your tool or even using script manager to run scripts at boot?
Sent from my GT-P7500 using Tapatalk
Click to expand...
Click to collapse
init.d triggered through the rom not the kernel, and it supports python scripts aswell
ricky310711 said:
init.d triggered through the rom not the kernel, and it supports python scripts aswell
Click to expand...
Click to collapse
Hi
I didn't understand this answer...
This solution also relies on init.d. Apart from python interpreting, what's the thing that makes it more robust aganist init.d scripts?
If a Rom (it's kernel) does not or only via 3rd part apps supports init.d, there could be problems the same.
Publiuss said:
Hi
I didn't understand this answer...
This solution also relies on init.d. Apart from python interpreting, what's the thing that makes it more robust aganist init.d scripts?
If a Rom (it's kernel) does not or only via 3rd part apps supports init.d, there could be problems the same.
Click to expand...
Click to collapse
what do you mean?
this doesnt rely on init.d, it is init.d.
this makes your device run init.d scripts WITHOUT the need to modify the kernel unlike some previous methods... but the scripts are called from /system/etc/startup/
the python script support is a featured currently in progress(from what i read)
ricky310711 said:
what do you mean?
this doesnt rely on init.d, it is init.d.
this makes your device run init.d scripts WITHOUT the need to modify the kernel unlike some previous methods... but the scripts are called from /system/etc/startup/
the python script support is a featured currently in progress(from what i read)
Click to expand...
Click to collapse
It does rely on init.d to call the "bse" binary, but I'm looking for an alternative method.
Sent from my Nexus 7 using Tapatalk
ricky310711 said:
what do you mean?
this doesnt rely on init.d, it is init.d.
this makes your device run init.d scripts WITHOUT the need to modify the kernel unlike some previous methods... but the scripts are called from /system/etc/startup/
the python script support is a featured currently in progress(from what i read)
Click to expand...
Click to collapse
Mhhh...
I'm not so expert, but I saw some metods using /etc/install_recovery.sh to call (another script that calls) run-parts to execute all /etc/init.d scripts, don't know if it's a way to make init.d work despite kernel not supporting it...
This one uses init.d itself to call bse executable so... well if init.d is no way supported it won't work?
Publiuss said:
Mhhh...
I'm not so expert, but I saw some metods using /etc/install_recovery.sh to call (another script that calls) run-parts to execute all /etc/init.d scripts, don't know if it's a way to make init.d work despite kernel not supporting it...
This one uses init.d itself to call bse executable so... well if init.d is no way supported it won't work?
Click to expand...
Click to collapse
justarchi has an init.d method where he calls the scripts from debuggerd!
The link is broken ... can upload? please!
Can anyone give me the download link of this tool

Resources