Database Info

LED debugging in Hero (6-22-09)

WOW OK SO I FINALLY GOT LED's WORKING IN HERO!!!
This means they can be manipulated via Terminal but not the Android OS. That will be the next step.
*IMPORTANT 4:50pm CST*
-Correction, you should be copying/symlinking sensors.msm7k.so to sensors.trout.so and not sensors.hero.so to sensors.trout.so. Please see updated instructions below.
If you already copied sensors.hero.so to sensors.trout.so then do the following to fix it. Following the previous instructions could affect auto rotate
Code:
rm /system/lib/hw/sensors.trout.so
ln -s /system/lib/hw/sensors.msm7k /system/lib/hw/sensors.trout.so
*Update 4:44pm CST*
-Changed copy commands to symlink so we save space on /system. Thanks for the tip chunga
*Update 6:01pm CST*
-If you're getting an issue where auto-rotate is no longer working it's most likely you fudged on the symlinking sensors.msm7k.so over to sensors.trout.so.
*Update 9:37pm CST*
-Forgot to add that you need to have /system remounted as read/write. I have added the command below
*Update 8:00pm CST*
The following command does not persist across reboots, therefore it will need to be placed in /init.rc or in /system/init.rc if you have a modded rom that allows for it. Just so everyone is clear, you can NOT edit /init.rc directly. To do that you'll need to unpack boot.img, edit init.rc, then repack boot.img and fastboot flash it to your device. My advice is to download a modded ROM that gets released with this fix.
Code:
echo "1" > /sys/devices/platform/i2c-adapter/i2c-0/0-0062/blink
It was a pretty trick fix to figure out. Here is a revised post with the complete terminal commands. ROM devs you could place these chmod commands in /init.rc to get it working. Please give credit where credit is due if you use my fixes.
Code:
[B]TERMINAL COMMANDS[/B]
mount -o rw,remount /dev/block/mtdblock3 /system
ln -s /system/lib/hw/lights.msm7k.so /system/lib/hw/lights.trout.so
ln -s /system/lib/hw/copybit.msm7k.so /system/lib/hw/copybit.trout.so
ln -s /system/lib/hw/sensors.msm7k.so /system/lib/hw/sensors.trout.so
echo "1" > /sys/devices/platform/i2c-adapter/i2c-0/0-0062/blink
chmod 666 /sys/devices/platform/i2c-adapter/i2c-0/0-0062/leds/blue/brightness
chmod 666 /sys/devices/platform/i2c-adapter/i2c-0/0-0062/leds/red/brightness
chmod 666 /sys/devices/platform/i2c-adapter/i2c-0/0-0062/leds/green/brightness
What's left to fix?
1) Currently the system is only giving the LED's a brightness of 1 so the light that comes on is dim. We need to find where it's getting this default value and up it to 100.
Want to manually change the colors?
You can edit the "brightness" value under leds/[blue/red/green] . The acceptable values are from 0 - 100. If you mix them up you can make any color you want
Exampe to change colors manually:
Code:
echo "50" > /sys/devices/platform/i2c-adapter/i2c-0/0-0062/leds/blue/brightness
echo "50" > /sys/devices/platform/i2c-adapter/i2c-0/0-0062/leds/red/brightness
This would make a purplish color.

okay so does it change colors when its charging after its cut on.

I believe the hero has dual LEDs. It says something about it in logcat...Let me see if i can find it.

jaygajay said:
I believe the hero has dual LEDs. It says something about it in logcat...Let me see if i can find it.
Click to expand...
Click to collapse
Yes it does in fact have dual LED's. So the trick now that LED's work is to get it working just like it was in cupcake. I'll keep working at it you can be sure of that

wizern23 said:
okay so does it change colors when its charging after its cut on.
Click to expand...
Click to collapse
I haven't seen it change colors as my phone is fully charged so the green LED comes on. Since we don't have bluetooth I can't check for the blue LED working. Anyone have chompsms installed? I know you can pick which LED color you want. Anyone wanna test that it's all working?

Terminal codes?
Hello! Thanks for the great fix!! But is there anyway you can post the entire terminal emu code? Kinda new on the copying and replacing of files. Thanks so much !

Try missed call, you can easily sample the different colors

phungshum said:
Hello! Thanks for the great fix!! But is there anyway you can post the entire terminal emu code? Kinda new on the copying and replacing of files. Thanks so much !
Click to expand...
Click to collapse
I updated the main post so others can easily find it

phungshum said:
Hello! Thanks for the great fix!! But is there anyway you can post the entire terminal emu code? Kinda new on the copying and replacing of files. Thanks so much !
Click to expand...
Click to collapse
this is actually editing the init.rc script... what do i open that in to edit it? and after edit can i just remount my system as writable and change the file names in my sys/lib/hw folder to the explained file names?

Zarboz said:
this is actually editing the init.rc script... what do i open that in to edit it? and after edit can i just remount my system as writable and change the file names in my sys/lib/hw folder to the explained file names?
Click to expand...
Click to collapse
You can type those commands from the terminal. If ROM devs want to make it so installing their ROM automatically does this, they would do it in init.rc.
You and I can do this from the terminal. It should hold those changes across a reboot. Hmmmm, lemme reboot and make sure otherwise it would require unpacking/repacking the boot.img and making the changes to init.rc in there. You can not edit init.rc directly. You have to extract boot.img (you can get this from the ROM you installed). Do a search for unpacking/repacking boot.img

great news

Good job shafty.

tried it, works, restarted my phone by itself after the echo though. Little confuse about the chmod stuff so not gonna try that yet. Oh did it in adb too, thanks.
EDIT: seemed to break my 'g-sensor', so no auto-rotate.

this is going into 1.65 Thanks shafty023 for the work!

running jacman hero and his lights.msm7k.so is already renamed do i need to worry about this and after the chmod lines after the /brightness/ can i enter a modifier to change the ammount of light given out?

just to clarify the terminal commands,
using JACMAN 1.64, files are already renamed.

Zarboz said:
running jacman hero and his lights.msm7k.so is already renamed do i need to worry about this and after the chmod lines after the /brightness/ can i enter a modifier to change the ammount of light given out?
Click to expand...
Click to collapse
Ya that's because he got it from justanothercrowd who got it from me. I was sending him most of my fixes directly since I'm using his ROM. Only seemed fair.
So you can ignore the line pertaining to lights.msm7k.
Yes you can feel free to change the value in brightness to whatever you want. I actually think the max is somewhere around 256. You can mix brightness values and that will allow you to change the colors manually. But unfortunately when you plug an a/c adapter it turns on the green led at a brightness value of only 1

so for example at the endo f my chmod 666 .... /brightness/100 ?? or would it be /brightness100

cool! thanks for the fix!

did nothing for me? wonder what i did wrong

[HACK] (!update 04/26/2010) JIT enabled Dalvik VM on Android 1.6 (Dusted Donuts)

Update (fix for /cache/dalvik-cache 04-26-2010): Really only use this if your having issues using the symbolic link fixes posted by other members or are just out of free space on /cache. First the new issues people are experiencing is in cm-based-kernels from 4.2.15.x and not JIT enabled DalvikVM and people using danger/death spl will experience problems faster. Lack of space on /cache is a problem and will cause market downloads to fail as well as email attachments. The other problem is the kernel fails for various and unknown reasons to mount bind /cache/dalvik-cache to /data/dalvik-cache.
The other issue is the use to dalvik-cache clearing scripts and options in RA recovery, stop clearing your dalvik-cache, the .dex files are created when missing and you do not get any benefits by doing so and cause more wearing leveling of NAND, plus the script in RA recovery doesn't appear to look at /cache/dalvik-cache for dex files. This little update script (when installed correctly).
Understand that /cache/dalvik-cache is a newer option as a means to free up space on /data is by using /cache/dalvik-cache as a first storage of dex files then using the standard /data/dalvik-cache for over flow of dex files and newer installed apps. Somewhere along the way something may throw this and you get douplicate dex files in both locations, one way to check is to boot into recovery and
Code:
mount -a
and check dalvik-cache directories in both /cache and /data for douplicate dex files.
The script will fix these issues, or should at least:
Endless loop FCs on boot
broken /cache/dalvik-cache mount
no binded mount
missing user apps
missing system apps
failed market downloads
non-working symlink patches and installers (no need to run these, they will break this patch)
fixes duplicate dex files in both /cache/dalvik-cache and <target>/dalvik-cache (because it deletes /cache/dalvik-cache)
Will not Fix:
your ignorance
your unwillingness to read
your unwillingness to learn
your compulsive ROM flashing disorder
your compulsive dalvik-cache clearing syndrome
version 1.1.1(updated 4/27/2010 @ 10:10 PM) is current and was slapped together from Phonekenstein, it doesn't look for the existance of /cache/dalvik-cache it assumes it's there and deletes it wether it's a directory, a symlink or a file, re-creates a new empty /cache/dalvik-cache with Android default permissions and mount binds it to /data/dalvik-cache (be it a directory, a symlink or another binded mount) /cache/dalvik-cache will follow the target /data/dalvik-cache (no worries for apps2sd users or non-apps2sd users).
Script will turn on the blue LED when booting so you know it executed (if it annoys you then edit the script and make it pink)
Tested on Cyanogen MOD 4.2.15.1 and SuperD 1.10.3:
with and without apps2sd
with and without a /dev/block/mmcblk0p2 (apps2sd script nulled)
with and without a custom /dev/block/mmcblk0p4
with mount binded /ext/dalvik-cache (mmcblk0p4) to /data/dalvik-cache
with /data/dalvik-cache as a symbolic link to /ext/dalvik-cache (mmcblk0p4)
All scenarios experienced no failures as long as you set your permissions correctly on all targets and files and /cache/dalvik-cache followed and binded flawlessly.
install is simple and can be done through terminal:
1. download 86dalvik-cache-fix <--Long press and chose "save link as" (also attached to this post)
2. open terminal and issue these commands:
NOTE: COMMANDS ARE CASE sensitive in LINUX and as such ANDROID!!!!!!
ALL OFF THESE COMMANDS ARE IN lower case. SO Turn off your Auto-Caps options in your keyboard options. These command assume you downloaded the script using your the web browser on your G1/Magic whatever phone and the file is located in /sdcard/download (the default location for web browser downloads).
Code:
su
mount -o rw,remount /system
cp /sdcard/download/86dalvik-cache-fix.txt /system/etc/init.d/86dalvik-cache-fix
chown 0:2000 /system/etc/init.d/86dalvik-cache-fix
chmod 755 /system/etc/init.d/86dalvik-cache-fix
sync
reboot
Why 86dalvik-cache-fix? We want the script to execute after all scripts in /system/etc/init.d/ including /system/sd/userinit.sh (if you are using one) and before script 99. 86 because in 1987 everything got 86'd.
If you are having a problem getting the script to execute, copy it or merge it into /system/sd/userinit.sh (even if you aren't using a mmcblk0p2(ext partition)) it may make it work with FastTest builds, however the permissions on his builds appear to be root everything and I have problems getting the script to execute out of /system/etc/init.d even with root permissions.
--------------------------------------------------------------------------------------------------------------
Primer: Read this about Dalvik VM http://en.wikipedia.org/wiki/Dalvik_virtual_machine
Read this to: Google Groups post about JIT compiler for Dalvik VM from Android-Platform Link
From the post we see that this particular compiled library is ALPHA, so results can vary, but from reading most posts in this thread the results are right near the talked about 3x faster code, stability is going to vary on what apps and or widgets are running. More Widgets = slower performance as these have processes that are eating cycles. When testing with Linpack wait for the advertisement to load first then tap the benchmark button and remove your finger from the touch screen. Background process such that interrupt or having auto-rotate enabled while testing is going to give you slower benchmarks.
In short your apps should load faster and run faster, particularly 3D games. The web browser is faster and you can actually scroll through pages even while graphics are still loading.
The reboot when enabling it is long even appearing to hang at the G1 Screen for 5 minutes or more but once it starts booting past this you will know that your ROM is compatible. The cause is that the dex files are being optimized, after about a third reboot, your ROM should feel pretty snappy and launching apps should be quicker as well as switching apps. The snappiness lasts as well and as some may have said that it's a placebo effect are wrong. Bench mark readings prove it and more importantly a few ROM builders have included this in their 2.1 ROMs as experimental.
The libdvm.so that t3steve cross compiled for the DROID at the time was for Android 2.0, the library works for with newer ROMs Android 1.6 that have some eclair pieces built into the kernel, CyanogenMOD has been using bits and pieces for a while now, if other ROM builders have been using his kernel and framework than a good chance it will work for your phone as well.
I have nothing to do with the compiling of this or the exact functions of enabling JIT except that I had a hunch that the combo might work and it did, so I'm sharing it.
If you aren't good at typing in commands, or don't know how to extract a zip file and understand that a sub folder may or may not exist where you have extracted said zip file to, well.... you may run into some issues, maybe a video tutorial for basic command line on youtube would be a good place to learn.
I wanted to make a very detailed post on www.andoidonroids.com about how to mash the JIT enabled Dalvik VM library into Android 1.6 Donuts I'm calling the hack "Dusted Donuts" and take from the name for what you will. I have been using the JIT enabled Dalvik VM for about two weeks and i runs decent but not perfect. Anyhow a death in the family Sunday has kept me from making a decent post and haven't had the time to get to the website and post and cross post and give credit where due.
No doubt that aaraya1516 broke the news on http://forum.xda-developers.com/showpost.php?p=5703076&postcount=193 as he was first to break the hack on FastTest, not taking anything away from him on that.
My testing goes back two weeks or more even during the 580mhz & 780mhz hack, I was waiting for someone to compile a boot.img with some 2.x stuff and sure enough the carlospants boot.img from ctso worked with enabling JIT for Dalvik VM, but as we know now the overclocking doesn't work at the moment.
Thank Cyanogen and t3hSteve of which may not know that this was entirely possible. Cyanogen mixed in enough Eclair into his Donuts (he's like Willy Wonka) that makes it possible to use the cross compiled JIT enabled Dalvik VM library from 2.1 for the Motorola DROID 2.0.1 libdvm.so that t3hSteve of www.alldroid.com compiled for the custom roms on Droid.
WARNING: Using other methods supplied from other forum members that include replacing the build.prop may cause problems, using the build.prop from the original VMLIBS.ZIP (which is here for reference and original source for libdvm.so) is definitely going to cause ROM and application problems. Hello....use your head here... the VMLIBS.ZIP is for Motorola DROIDS, why would you put the build.prop file for a DROID on your G1 and expect your apps or ROM to work afterwards? It's so simple, you need 1 file, it's called libdvm.so it goes in /system/lib a file by the same name already exists there and it's in your best interest to at least back it up before overwriting it and gives you the ability in the event that your system doesn't boot up you can restore it through recovery console and get your phone to boot past the G1 screen.
FYI: Some ROMs have the option dalvik.vm.execution-mode=int:fast in the /system/build.prop file, this would need to be changed to dalvik.vm.execution-mode=int:jit or commented out or deleted. If you want to play with advanced options create /data/local.prop and fiddle in there with options available from typing dalvikvm -h in your console or terminal app.
Required:
1. Android 1.6 ROMS with a bit Eclair stuff in the Kernel and framework such as Cyanogen ROM 4.2.x, Super D 1.8 - 1.92, WG Y2.6, FastTest, KingKlick Eclair and more.. This libdvm.so works on Android 2.1 as well as it seems it should.. 1 st bootup is slow and I recommend you let it sit even when desktops are up for a couple of minutes and then reboot it, 2nd and 3rd bootups are faster and smoother response overall even for long durations, days.
FIX YOUR FILE SYSTEM FIRST !!!!!! Got to do it from Recovery Console, It's partly the cause of poorly running ROMS and takes seriously longer to type the command than to fix your unknowingly faulty file system. EXT2 is the worst offender and the built in function to repair falls short, even more so when checking EXT4.
Code:
#e2fsck -fcpDC0 /dev/block/mmcblk0p2
#reboot recovery
For the lazy fingers
#e2fsck -fcpDC0 /*/*/*0p2
#reboot recovery
1. Download www.androidonroids.com/dusted-donuts (File has 3 scripts backup, install, restore, 2 folders, 1 libdvm.so)
2. Extract zip to root of /sdcard or where ever you like (the zip has a folder containing the files named dusted-donuts)
3. Open Terminal or go to Recovery Console
FYI when running the install through Terminal your system may freeze or reboot and if it does I highly recommend that you prepare to enter Recovery Mode and check your file system. EXT2 corrupts quickly choosing this for apps2sd to use is not the best option especially if you are using custom ROMs that may lockup or reboot, basically that's a crash.
Code:
$su
#mount -o rw,remount auto /sdcard
#cd /sdcard/dusted-donuts
#sh backup
#sh install
#sync
#reboot
Check the Dalvik VM execution mode. look at the bottom line with_jit means the it is installed , and look at all of those options that can be jammed into your build.prop and local.prop files
Code:
$su
#dalvikvm -h
Phone won't boot past G1 screen? Go to recovery console and restore libdvm.so (give it at least 5 minutes first before giving up)
Code:
#mount -o rw,remount auto /sdcard
#cd /sdcard/dusted-donuts
#sh restore
#sync
#reboot
---------------------------------------------------------------------------------------------------------------------
prefer to use VMLIBS.ZIP from t3hSteve? This is how you can install using that.
Required:
1. Android 1.6 ROMS with a bit Eclair stuff in the Kernel and framework such as Cyanogen ROM 4.2.x, Super D 1.8 - 19.2, WG Y2.6, FastTest, KingKlick Eclair and more.. This libdvm.so works on Android 2.1 as well as it seems it should..
How to install: (easier to go in recovery mode but can be done through terminal)
1. Download the VMLIBS.ZIP from t3hSteve of allroid.com http://alldroid.org/download/file.php?id=1374
2. You only need the libdvm.so file of which appears to be JIT enabled by default.
3. Backup the original libdvm.so #cp /system/lib/libdvm.so /sdcard/libdvm.so
4. Copy the JIT enabled libdvm.so #cp -f /sdcard/vmlibs/libdvm.so /system/lib/libdvm.so
5. Set permissions on the file #chmod 644 /system/lib/libdvm.so
Optional for disabling: (easier to do vi through recovery console, since the back key escapes out of terminal)
To disable JIT MODE but want to keep the libdvm.so create a local.prop in /data and add dalvik.vm.execution-mode=int:fast
#vi /data/local.prop
press the i key to enter vi interactive mode
type dalvik.vm.execution-mode=int:fast
press back key to exit vi interactive mode
to write the file out and quit vi type :wq
or
restore your backed libdvm.so file from the sdcard.
-----------------------------------------------------------------------------------------------------------------------
Enjoi! the dusted donuts,
-Licknuts (me? I'm like Varuca Salt, I want another pony)
Vendor G1 roms around 1.2 Mflops, Custom G1 roms are around 2.4 MFlops/s and with JIT compiled Dalvik VM 3.6 MFlops/s. At most you will see 3.5 MFlops/s fairly consistently with a minimal load on your system and highs at 3.7 Mflops/s. Test before and after using Linpack from the Market, it's free.
The 13.236 Mflops/s is not normal and you will probably not see with your testing, I have seen 5.x & 7.x but these are far and few between and this took a while with tweaked configurations/settings with a persistent app to kill processes, it is attainable and I hope a ROM developer finds the sweet spot to exploit.

Looks nice.
Pre-JIT enabled: 2.194 Mflops/s
Post-enabled: 3.459 Mflops/s
Not quite getting the results you have there.
Running SuperD 1.9.2 Black W/ Nexus Theme. I copied it twice to make sure that the libdvm.so was copied correctly to the directory. Rebooted the phone, same results. Looks very promising though. If I did something wrong, lemme know.
Managed to get #10 on G1 Benchmarks with 3.583 Mflops/s... still nowhere near 13.~ Mflops/s

same here. Running Super D 1.9 on my magic
before JIT I got 1.xxxx Mflops/s
after i have 2.xxxx Mflops/s
how do you get the 13 Mflops/s ?
-edit-
with swap disabled i'm getting 3.5 Mflops/s

h.nocturna said:
Looks nice.
Pre-JIT enabled: 2.194 Mflops/s
Post-enabled: 3.459 Mflops/s
Not quite getting the results you have there.
Running SuperD 1.9.2 Black W/ Nexus Theme. I copied it twice to make sure that the libdvm.so was copied correctly to the directory. Rebooted the phone, same results. Looks very promising though. If I did something wrong, lemme know.
Managed to get #10 on G1 Benchmarks with 3.583 Mflops/s... still nowhere near 13.~ Mflops/s
Click to expand...
Click to collapse
I got 9 seconds on the pi benchmark

What will this do??

samsara00 said:
same here. Running Super D 1.9 on my magic
before JIT I got 1.xxxx Mflops/s
after i have 2.xxxx Mflops/s
how do you get the 13 Mflops/s ?
-edit-
with swap disabled i'm getting 3.5 Mflops/s
Click to expand...
Click to collapse
So I guess this only works with Swap off?
sabin123 said:
What will this do??
Click to expand...
Click to collapse
Speed your *hit up!

it works with and without swap.
Just the benchmark result is better when swap is turned off.
Got nearly the same as samsara00:
Rom: SuperD 1.9.2
Before (swap off): ~ 2.3 MFlops/s
After JIT enabling (swap off): ~ 3.5 MFlops/s
But the increase to 13.x seems so unreal, why is there only one result that high in the toplist of greene.com!?

Now to find out if this actually speeds up everyday use lol
CM4.2.14.1
Before: 2.3
After: 3.5
Wow! This made my 3G connection faster too. Was only getting 1500kbps before, now getting on average 3200kbps. Awesome. I'm located in Toronto, on Rogers.
Question: Is this Google's JIT? Will Myraids Dalvik Turbo be faster?

Doesn't boot past the G1 screen when using Dwangs 1.17.1 Assume thats because it has no Eclair in it, but it was worth the dream .

Waw!! great works!!
left is before - right one is after
on CM 4.2.14.1, enabled Swap 64MB, CC ON, RAM Hacked

So do we copy the zip to the root of our sd card? Do I extract it first and just copy the one file? The instructions are kind of vague.

G1ForFun said:
So do we copy the zip to the root of our sd card? Do I extract it first and just copy the one file? The instructions are kind of vague.
Click to expand...
Click to collapse
Not to be rude, but if you don't understand those directions, this isn't the sort of thing you should try to do yourself. Wait for a ROM builder to add this in. The directions are perfectly clear, you just need to understand command line use.
If you want to learn something about CLI use, install Linux on your computer and learn to use it without the GUI. If you don't want to do that, google for "cygwin" and use the bash shell they provide for Windows based machines.

Personally, I used adb and just pushed the darn file lol works perfectly fine, like everything else I've ever pushed. Just don't forget to set the permissions for the file.

tried in a terminal and with adb getting read-only file system when trying to copy over the libdvm.so file

SilentTweak said:
Personally, I used adb and just pushed the darn file lol works perfectly fine, like everything else I've ever pushed. Just don't forget to set the permissions for the file.
Click to expand...
Click to collapse
Nothing wrong with adb. Hell, I used SSH to do it. Just about anything will work, you just have to know what you're doing.
Damn.... I just rebooted and it took about half the time it used to.
Tried the Linpack benchmark, getting about 3.5 with SuperD 1.9.2 w/Compcache 16M swappiness=10. Fresh reboot, obviously. Lock your CPU to 528 (min and max) for more consistent results. When I have 128min 528max, it gives different results depending on the current CPU speed. SetCPU or Overclock Widget helps a lot here. No instability noticed yet, but this should probably be considered an unstable hack for now till we all get more experience with it. I know OpenEclair removed the JIT VM because of stability problems.

Sgt.EddieWinslow said:
tried in a terminal and with adb getting read-only file system when trying to copy over the libdvm.so file
Click to expand...
Click to collapse
Do "adb remount" first

ttabbal said:
Not to be rude, but if you don't understand those directions, this isn't the sort of thing you should try to do yourself. Wait for a ROM builder to add this in. The directions are perfectly clear, you just need to understand command line use.
If you want to learn something about CLI use, install Linux on your computer and learn to use it without the GUI. If you don't want to do that, google for "cygwin" and use the bash shell they provide for Windows based machines.
Click to expand...
Click to collapse
Obviously they are not clear to me. Why argue the point?
I have worked plenty with cmd type interfaces...so please...put down your know it all stick and be helpful.
edit: hope this helps somebody else...look better instructions posted in the fasttest thread!
download files here and copy them on the sdcard
created a folder /sdcard/jit and put the three files in it
make a folder /sdcard/dalbk and copy the original files
adb pull /system/build.prop .
Open in WordPad/Textpad and add as the last line: dalvik.vm.execution-mode=int:jit
SAVE IT, copy/push it on the /sdcard/jit folder

Sgt.EddieWinslow said:
tried in a terminal and with adb getting read-only file system when trying to copy over the libdvm.so file
Click to expand...
Click to collapse
Code:
C:\Android\tools>adb shell
# su
su
# mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
# chmod 777 /system/lib/libdvm.so
chmod 777 /system/lib/libdvm.so
# cp -f /sdcard/vmlibs/libdvm.so /system/lib/libdvm.so
cp -f /sdcard/vmlibs/libdvm.so /system/lib/libdvm.so
# chmod 644 /system/lib/libdvm.so
chmod 644 /system/lib/libdvm.so
# reboot
Damn.... I just rebooted and it took about half the time it used to.
Click to expand...
Click to collapse
Indeed
Licknuts result : 3.1-3.5 (with Super-D 1.9.2)

My method of installing it:
adb remount
adb push libdvm.so /system/lib/libdvm.so
Then open console and type:
su
chmod 644 /system/lib/libdvm.so
reboot

I'm about to try this myself.. has anyone noticed an overall increase in speed? Benchmarks are great but it's all about how it actually performs!
I'll post my own findings in a bit.

Better integrating Busybox (2012-11-17)

Most Android ROMs use toolbox as primary binary with symlinks in /system/bin and /system/xbin. The problem with toolbox is that it sucks. On some ROMs it's even so limited that it does not even allow for --prefix
Busybox is a great replacement for toolbox, but in order to use it, you have to call it using 'busybox cmd'. I would much rather use it by calling 'cmd' but this would execute toolbox instead of busybox.
Most would think the command 'busybox --install' would fix this, but it does'nt. It tries to install links at /bin and /sbin.
The script below will replace any toolbox links in /system/bin and /system/xbin that is supported by the busybox version installed on the Android device running the script. This will make busybox the default binary when executing regular commands without adding 'busybox' at the beginning of the command.
For an example 'ls' instead of 'busybox ls'
Download as an update.zip
v1.3.0 (Nov 17, 2012) (MD5: c233964f0f62a16d7376739041e8b250) - busybox_installer.zip (Only for ArmV7 devices)
v1.3.0 (Nov 17, 2012) (MD5: e921a6c4119644a18d4feea565824ab1) - busybox_installer-nobin (Without binaries)
busybox.sh
Code:
#!/sbin/sh
for cmd in test find basename readlink ln rm; do
eval export "_$cmd=\"/sbin/busybox $cmd\""
done
_busybox=$($_find /system -type f -name "busybox")
_toolbox=$($_find /system -type f -name "toolbox")
if $_test -e "$_busybox" && $_test -e "$_toolbox"; then
sToolboxList="watchprops wipe vmstat date uptime reboot getevent getprop setprop id iftop ioctl ionice log lsof nandread newfs_msdos notify ps r schedtop sendevent setconsole setprop sleep smd start stop top"
sBusyboxList="`$_busybox --list`"
for applet in $sBusyboxList; do
if $_test -L /system/bin/$applet; then
if $_test "`$_basename $($_readlink -f /system/bin/$applet)`" = "toolbox"; then
$_ln -sf $_busybox /system/bin/$applet
if $_test -L /system/xbin/$applet; then
$_rm -rf /system/xbin/$applet
fi
fi
elif $_test -L /system/xbin/$applet; then
if $_test "`$_basename $($_readlink -f /system/xbin/$applet)`" = "toolbox"; then
$_ln -sf $_busybox /system/xbin/$applet
fi
elif ! $_test -e /system/bin/$applet && ! $_test -e /system/xbin/$applet; then
$_ln -sf $_busybox /system/bin/$applet
fi
done
for applet in $sToolboxList; do
$_ln -sf $_toolbox /system/bin/$applet
done
fi
Toolbox install links
watchprops, wipe, vmstat, date, uptime, reboot, getevent, getprop, setprop, id, iftop, ioctl, ionice, log, lsof, nandread, newfs_msdos, notify, ps, r, su, schedtop, sendevent, setconsole, setprop, sleep, smd, start, stop, top
Busybox install links
Whatever the currently installed busybox supports that is not in the list of toolbox install links
Change log
Dec 10 2011, 21:39 UTC:
The script will now leave skip replacing /system/bin/reboot as it needs to be pointed at toolbox
Dec 11 2011, 10:08 UTC:
Added an update zip that will configure busybox and it provides an extended 1.4MB binary instead of the regular 480KB most ROM's provide
Dec 12 2011, 09:25 UTC:
Added new busybox build (1.20.0.git 2011-12-11) since there was problem with the old one for some people
Added more busybox search dirs (/system/sbin and /sbin)
Added Toolbox install to make sure that some android specific links uses toolbox instead of busybox. See list above.
Jun 27 2012, 13:45 UTC:
Better Busybox and Toolbox search
Added symlink check to make sure that busybox only replaces toolbox links and not things like "sh -> mksh"
Nov 17 2012, 10:30 UTC:
Added a custom toolbox binary to the ArmV7 installer
Added latest CM9 busybox binary to the ArmV7 binary
Added an auto search function to locate the binaries on the device
Fixed both installers to work with newer devices that uses EXT4 file system

Thanks, dk_zero-cool. I've been looking for a guide to installing BusyBox, since I can only find an add-supported installer in the Android Market.

Thanks, nice job!!

Ran the script, worked and did fine....ONE BIG ISSUE....now if you have any script or app that relies on the "reboot" function, it no longer works. For example, rom manager & bootstrapper will not boot into recovery. I even open up terminal and typed:
Code:
$ su
# reboot
...and nothing...does the reboot in /bin need to not be linked to busybox?

KMDonlon said:
Ran the script, worked and did fine....ONE BIG ISSUE....now if you have any script or app that relies on the "reboot" function, it no longer works. For example, rom manager & bootstrapper will not boot into recovery. I even open up terminal and typed:
Code:
$ su
# reboot
...and nothing...does the reboot in /bin need to not be linked to busybox?
Click to expand...
Click to collapse
Try to relink it back to toolbox and then I will update the script to leave reboot alone.
1: mount -o remount,rw /system
2: rm -r /system/bin/reboot
3: ln -s /system/bin/toolbox /system/bin/reboot

Great! Will try again!

Cool... can I steal this?
I'd implement it with a busybox install script
I'm not a super expert on the subject but is /system/sbin a possible location?

zeppelinrox said:
Cool... can I steal this?
I'd implement it with a busybox install script
I'm not a super expert on the subject but is /system/sbin a possible location?
Click to expand...
Click to collapse
You can use this as you like.
And you can type "echo $PATH" in an adb shell, if /system/sbin is there, then it will work. But why? /system/xbin is usually the default dir for placing busybox, otherwise /system/bin. And you will have to change the script since it will only check in /system/bin and /system/xbin

All times in my scripts report UTC time instead of system time, I am sure there is one other applet in /bin that was linked to toolbox that is now linked to busybox and reporting the date wrong or at least the date/time that busybox says (UTC time).

KMDonlon said:
All times in my scripts report UTC time instead of system time, I am sure there is one other applet in /bin that was linked to toolbox that is now linked to busybox and reporting the date wrong or at least the date/time that busybox says (UTC time).
Click to expand...
Click to collapse
Do the same as before, only this time replace 'reboot' with 'date'
This must be a setting in the busybox compile menu. A new binary might fix this because busybox should be able to display system time. But for now point date back to toolbox and it will work for you.

Yup, did what you just said and all is fine. Thanks! Is there a way you can implement the reboot and date applet ignore in the script within the .zip you made.... I think it will save users some headaches.

dk_zero-cool said:
You can use this as you like.
And you can type "echo $PATH" in an adb shell, if /system/sbin is there, then it will work. But why? /system/xbin is usually the default dir for placing busybox, otherwise /system/bin. And you will have to change the script since it will only check in /system/bin and /system/xbin
Click to expand...
Click to collapse
Well bb is sometimes installed elsewhere.
At first SuperCharger only looked in those 2 locations and stopped when it wasn't found.
What would happen if there was a second version elsewhere?
I suppose it wouldn't matter because of the symlinks.

KMDonlon said:
Yup, did what you just said and all is fine. Thanks! Is there a way you can implement the reboot and date applet ignore in the script within the .zip you made.... I think it will save users some headaches.
Click to expand...
Click to collapse
The reboot fix is already in the zip file.
The date fix I don't want in it, I would much rather fix busybox to work properly.
I'm currently looking at that.
zeppelinrox said:
Well bb is sometimes installed elsewhere.
At first SuperCharger only looked in those 2 locations and stopped when it wasn't found.
What would happen if there was a second version elsewhere?
I suppose it wouldn't matter because of the symlinks.
Click to expand...
Click to collapse
No that does not mater because of the symlinks.
That's why I referrer to the complete path, f.eks, "/system/xbin/busybox" and not just the binary name "busybox".

I am going to try your binary for Busybox and see, I am currently using JRummy's BB installer which installed v1.19.3 which is about 1.06MB....
EDIT: Just flashed the .zip, my phone will not boot past the logo....did a battery pull several times and can't get into CWR....SBF time

KMDonlon said:
I am going to try your binary for Busybox and see, I am currently using JRummy's BB installer which installed v1.19.3 which is about 1.06MB....
EDIT: Just flashed the .zip, my phone will not boot past the logo....did a battery pull several times and can't get into CWR....SBF time
Click to expand...
Click to collapse
Put in your USB cable, open a terminal/console on your computer and try "adb logcat" to see what it says when it stops booting.
You must of cause have adb installed on your computer, and USB drivers if you use windows, which I don't and cant help with.

Already reflashed phone back....sorry, no logcat....

Do it again...
C'mon take one for the team... hehe...

LMFAO!!!! Sorry dude, I ain't gonna do it....will let some other poor soul ....I got honey do's today, it's Sunday!!

Whatever it was I can't recreate it. Works fine when I flash the damn thing.

Here's a thought.....make a script that reverses the toolbox links, I can undo it and try to flash again....I was unable to manually install your busybox version so I think some other toolbox applet is causing me trouble.....

[SOLVED] [Q] [CM 10.2] Two questions about USB debugging and fsync control

Hello.
1. I can't find development/enable USB debugging. Where did it go?
2. I found '/sys/module/sync/parameters/fsync_enabled'.
I assume kernel support for fsync control is available.
Is that exposed in a UI? Or do I have to set it via a script?
What is the recommended way to execute stuff at start up? [I don't see /etc/rc.local available ]
BTW, executing 'exit' in terminal seems to get stuck here. Can someone confirm?
* I'm experience in GNU/Linux and *nix in general but I'm new to Android.

tf700_13 said:
Hello.
1. I can't find development/enable USB debugging. Where did it go?
2. I found '/sys/module/sync/parameters/fsync_enabled'.
I assume kernel support for fsync control is available.
Is that exposed in a UI? Or do I have to set it via a script?
What is the recommended way to execute stuff at start up? [I don't see /etc/rc.local available ]
BTW, executing 'exit' in terminal seems to get stuck here. Can someone confirm?
* I'm experience in GNU/Linux and *nix in general but I'm new to Android.
Click to expand...
Click to collapse
1. Go to settings and about, click the build number 7 times and developer options will be made available.
2. Usually set it via a startup script. Assuming the cm10 kernel supports it.

sbdags said:
1. Go to settings and about, click the build number 7 times and developer options will be made available.
Click to expand...
Click to collapse
Done! Thanks.
2. Usually set it via a startup script. Assuming the cm10 kernel supports it.
Click to expand...
Click to collapse
Is there a recommended way/app to manage startup scripts?
And just to make sure, /sys/module/sync/parameters/fsync_enabled is set to 1. I need to set it to 0 to disable fsync (not some other value), right?

tf700_13 said:
Done! Thanks.
Is there a recommended way/app to manage startup scripts?
And just to make sure, /sys/module/sync/parameters/fsync_enabled is set to 1. I need to set it to 0 to disable fsync (not some other value), right?
Click to expand...
Click to collapse
Yes set it to 0. Just echo it in a script. In my ROM I use init.d enabled scripting to achieve this. I think cm uses the same theory but does it slightly differently.
I'll post my script later when I get home.

sbdags said:
Yes set it to 0. Just echo it in a script. In my ROM I use init.d enabled scripting to achieve this. I think cm uses the same theory but does it slightly differently.
I'll post my script later when I get home.
Click to expand...
Click to collapse
I know how to write scripts And yes, /etc/init.d/ is used.
So all I need is adding a file there (e.g. 80disablefsync) with content:
Code:
#!/system/bin/sh
echo 0 > /sys/module/sync/parameters/fsync_enabled
Assuming that is correct, I'm stuck now at writing a file there.
The *nix way 'mount -o remount,rw /' is not working.
Read-only file system error didn't go away.

tf700_13 said:
The *nix way 'mount -o remount,rw /' is not working.
Read-only file system error didn't go away.
Click to expand...
Click to collapse
You have to remount /system, not /.
Another workaround: You could use /data/userinit.d instead (don't know if that is the exact name).

_that said:
You have to remount /system, not /.
Another workaround: You could use /data/userinit.d instead (don't know if that is the exact name).
Click to expand...
Click to collapse
I could have sworn I didn't see a mount point for /system earlier.
Anyway all is good now.
Thank you guys.
The only problem remaining is C-d not exiting in terminal. and executing exit afterwards gets stuck. But that's not a big deal.

tf700_13 said:
The only problem remaining is C-d not exiting in terminal. and executing exit afterwards gets stuck. But that's not a big deal.
Click to expand...
Click to collapse
Preferences -> Close window on exit [x] ?

_that said:
Preferences -> Close window on exit [x] ?
Click to expand...
Click to collapse
That's already checked and works.
The problem is, CTRL-d is an escape sequence that should exit and it's not working when you're root.

[APP/FIX] Date/Time 1970 bug workaround v2.2

Hope this helps someone. I got fairly sick of the date/time bug giving me error alerts upon reboot. This fix takes the RTC date/time and applies an offset specific to your own phone to set the correct date/time at startup. I have attached an APK to make life easy. It should also give the ability to have recovery use the files it creates to set the clock correctly on startup.
The app requires root. If running AOSP, your ROM must have initscript support.
The app has 3 functions:
Install offset only (for use with a compatible recovery, not used by the ROM)
Install offset and initscript (to correct ROM clock offset, also for use with a compatible recovery)
Uninstall (Remove /data/local/userinit.sh /data/media/rtc_offset and /sdcard/rtc_offset)
Feel free to include the app in your own ROMs, just give me credit
As of version 2.0, the script will create /data/media/rtc_offset which can be used by recovery to correct the date/time on boot. Note this will require the recovery to specifically support this correction.
Version 2.1 uses /system/bin/toolbox for compatibility across roms (rather than relying on whatever /system/bin/date points to)
Version 2.2 places the rtc_offset file both in /sdcard/rtc_offset and also in /data/media/rtc_offset if available. The initscript will use either file that is available. This is for possible compatibility with older phones that may not have /data/media, at the request of Phil3759
Special thanks to Atze001, sniperle and Phil3759.
Hope this helps, enjoy.

dougiebee said:
Hope this helps someone. I got fairly sick of the date/time bug giving me error alerts upon reboot. My solution was to get the modification date of the /data/system directory and set that as the current date at boot time. Not great, but better than 1970. This or something similar may be posted elsewhere but I haven't seen it.
I'm running CM11 - not sure whether this works on other AOSP ROMS.
1) Create a file named 01datehack with the following content:
Code:
#!/system/bin/sh
olddate=`ls -ld /data/system | awk '{print $4, $5}' | sed -e 's/-//g' -e 's/ /./g' -e 's/://g' -e 's/$/00/g'`
date -s $olddate
Then run the following commands:
Code:
adb root
adb shell "mkdir -p /data/local/userinit.d"
adb push 01datehack /data/local/userinit.d
adb shell "chmod 755 /data/local/userinit.d/01datehack"
As it lives in /data it will survive flashing an update as long as you don't wipe. It's only a couple of fairly noddy linux commands, there's quite possibly a command line switch that would negate the need for all the SED'ing - also possibly a better directory/file to look at.
Hope this helps, enjoy.
Click to expand...
Click to collapse
I'm on the latest cm11 nightly. Tried your code but didn't make any difference. Phone still started up in February and then changed to today's date after network/WiFi started.

murdoch1 said:
I'm on the latest cm11 nightly. Tried your code but didn't make any difference. Phone still started up in February and then changed to today's date after network/WiFi started.
Click to expand...
Click to collapse
What do you get from "adb shell ls -ld /data/system"? Have you enabled ADB root access in developer options?

1970
dougiebee said:
What do you get from "adb shell ls -ld /data/system"? Have you enabled ADB root access in developer options?
Click to expand...
Click to collapse
Yes enabled ADB root access in Developer options. Running the command you provided results me with the following:-
drwxrwxr-x system system 2013-12-23 08:47 system
Cheers

deleted

Try this. I have made a flashable zip for TWRP
http://forum.xda-developers.com/showpost.php?p=48760802&postcount=13
Its a userinit.sh script in data/local

Atze001 said:
Try this. I have made a flashable zip for TWRP
https://dl.dropboxusercontent.com/u/20033515/TimeDateFix.zip[/U
Its a userinit.sh script in data/local
Click to expand...
Click to collapse
Will this work for me as I'm running philz cwm?

You can try it. If it dont work you get an Installation error and nothing more happens.
If you get an Error please tell me i will fix it for CWM.

Atze001 said:
You can try it. If it dont work you get an Installation error and nothing more happens.
If you get an Error please tell me i will fix it for CWM.
Click to expand...
Click to collapse
Just installed. Worked perfectly phone booted up with the correct date immediately.
Many thanks. Have a good Xmas.

Thanks go to dougiebee for this work.

Works perfectly on CM11 and TWRP.
Thanks a lot dougiebee and Atze001. :laugh:

Works on CM11/D802/TWRP!
Gesendet von meinem LG-D802 mit Tapatalk

Here are the new Links for the flashable fix.
This one ist with userinit.sh in data/local
https://dl.dropboxusercontent.com/u/20033515/TimeDateFix/TimeDateFix_Local.zip
and this ist the original with 01datehack in data/local/userinit.d
https://dl.dropboxusercontent.com/u/20033515/TimeDateFix/TimeDateFix_org.zip

Atze001 said:
Here are the new Links for the flashable fix.
This one ist with userinit.sh in data/local
https://dl.dropboxusercontent.com/u/20033515/TimeDateFix/TimeDateFix_Local.zip
and this ist the original with 01datehack in data/local/userinit.d
https://dl.dropboxusercontent.com/u/20033515/TimeDateFix/TimeDateFix_org.zip
Click to expand...
Click to collapse
thanks, but you didn't set permission to 755 in your script, that's why it doesn't work. i'm sure you can fix it

I personally use the first zip and it works. Many people confirmed that it works.
But if you want i can set the permissons to 755
Permissions fixed

I now have a much better fix. It uses the RTC rather than relying on file timestamps. It's easy to implement, but creation of a flashable zip will not be straight forward.
I ran the following using ADB once the system was up and the date/time was correct:
Code:
expr $(date +%s) - $(cat /sys/class/rtc/rtc0/since_epoch)
Which gave me 1384422218 - which is "Thu Nov 14 09:43:38 GMT 2013" - the exact date/time I first powered on my phone after I got it.
So I edited my userinit file to read:
Code:
#!/system/bin/sh
realdate=$(expr 1384422218 + `cat /sys/class/rtc/rtc0/since_epoch` | awk '{print strftime("%Y%m%d.%H%M%S",$1)}')
date -s $realdate
This takes my hard-coded (device-specific) power-on time and adds the current RTC time since then to give me the correct date/time, much better than using the timestamp of a file or directory.
I'll update the OP if others confirm this works for them. Note: you need to replace 1384422218 with the number specific to your phone. Creating a flashable zip would be a bit of a challenge, as it would need to be device specific.

Wouldn't it be possible to add a script to the flashable zip that determines the correct value and modifies the flashable file with the value before or after flashing?
PS: I don't know anything about this stuff...

dougiebee said:
I now have a much better fix. It uses the RTC rather than relying on file timestamps. It's easy to implement, but creation of a flashable zip will not be straight forward.
I ran the following using ADB once the system was up and the date/time was correct:
Code:
expr $(date +%s) - $(cat /sys/class/rtc/rtc0/since_epoch)
Which gave me 1384422218 - which is "Thu Nov 14 09:43:38 GMT 2013" - the exact date/time I first powered on my phone after I got it.
So I edited my userinit file to read:
Code:
#!/system/bin/sh
realdate=$(expr 1384422218 + `cat /sys/class/rtc/rtc0/since_epoch` | awk '{print strftime("%Y%m%d.%H%M%S",$1)}')
date -s $realdate
This takes my hard-coded (device-specific) power-on time and adds the current RTC time since then to give me the correct date/time, much better than using the timestamp of a file or directory.
I'll update the OP if others confirm this works for them. Note: you need to replace 1384422218 with the number specific to your phone. Creating a flashable zip would be a bit of a challenge, as it would need to be device specific.
Click to expand...
Click to collapse
Just applied your new version. Works a treat. As you say its better than basing the date on a file timestamp. I basically used the flash zip and amended the unserinit.sh script with the code generated on my device.
All done.
Cheers again.

With 01datehack in userinit.d it dont work for me. With userinit.sh in local it works.
I will take a look to make a Batch or a zip out of this.

dougiebee said:
I now have a much better fix. It uses the RTC rather than relying on file timestamps. It's easy to implement, but creation of a flashable zip will not be straight forward.
I ran the following using ADB once the system was up and the date/time was correct:
Code:
expr $(date +%s) - $(cat /sys/class/rtc/rtc0/since_epoch)
Which gave me 1384422218 - which is "Thu Nov 14 09:43:38 GMT 2013" - the exact date/time I first powered on my phone after I got it.
So I edited my userinit file to read:
Code:
#!/system/bin/sh
realdate=$(expr 1384422218 + `cat /sys/class/rtc/rtc0/since_epoch` | awk '{print strftime("%Y%m%d.%H%M%S",$1)}')
date -s $realdate
This takes my hard-coded (device-specific) power-on time and adds the current RTC time since then to give me the correct date/time, much better than using the timestamp of a file or directory.
I'll update the OP if others confirm this works for them. Note: you need to replace 1384422218 with the number specific to your phone. Creating a flashable zip would be a bit of a challenge, as it would need to be device specific.
Click to expand...
Click to collapse
Does this survive flashing or do I need to do this every time I flash?
Sent from my LG-VS980 using Tapatalk