SD Tweakz - Run your scripts on SD at boot-time. (Plus few battery tweaks)

SD Tweakz - Run your scripts on SD at boot-time. (Plus few battery tweaks) - Optimus One, P500 Android Development

SD Tweakz v2
Only works on custom ROMs with init.d(aka busybox runparts) support
UPDATED 04/11/11(added a few battery tweaks)
Wondering around on XDA will sometimes lead you to threads with scripts/tweaks that may or may not help you improve your android device in one way or another. Now most of these scripts/tweaks are not boot resistant. Meaning, after rebooting the tweaks gets disabled and you need to enter/execute them once again.
Well here's another script that would help you initialize those scrips/tweaks every time you restart/reboot you phone and make your life a lot more easier.
Instructions / How does it work?
1. Download the initial script here (SD Tweakz v2)
2. Flash via recovery This will install/copy the initial script into a portion of your android system which initializes/runs every time the phone boots
3. Create a folder on SD called "scriptz" (/sdcard/scriptz)
4. Place your tweaks/scripts inside "scriptz" folder. Usefull scripts/tweaks with explanation below
5. Reboot and see your script run on boot time By this point, every time you boot, the initial script will check your sdcard(/sdcard/sctiptz) if any scripts/tweaks are present. Once found it will then run the scripts for you each and every time you boot
What is it good for
Well there are lots of tweaks out there just waiting to be discovered. Some can yield great performance and some can provide you with a better battery management that can extend your battery life for hours. Unfortunately, some tweaks can only give you one of the benefits above and a bad performance on the other. Meaning you just can't have 'em all. Here you can choose which tweaks/scripts to apply, modify the values as you want as well as debugging which script provides the benefits that you expect. Another reason for using this mod is compatibility as some tweaks/scripts can be ROM dependent. Most of the time it's a kernel issue but some libraries can get involved too.
The Scripts
Scripts are just plain linux compliant text document which has certain linux commands that can be issued using adb/terminal.
You can make one yourself using some android text editors(from es file explorer, dropbox, root explorer etc.). Don't forget to add a ".sh" file extension.
Here's a few example of the scripts I use:
Code:
#These scripts are from various sources from different sites including [URL="http://forum.samdroid.net/"]Samdroid.net[/URL]
#And of course in collaboration with FranciscoFranco
#
#My approach in the scripts/tweaks that I use is basically just to
#squeeze more juice out of my phone. So in contrast to the tweaks
#included in FranciscoFranco's thread, the tweaks/scripts I use are less
#aggressive in terms of performance and more inclined to save battery.
#
#non-rotational.sh
#this script tells android that you are not using spinning disks
DM=`ls -d /sys/block/dm*`;
MTD=`ls -d /sys/block/mtd*`;
LOOP=`ls -d /sys/block/loop*`;
RAM=`ls -d /sys/block/ram*`;
for j in $DM $MTD $LOOP $RAM;
do
echo 0 > $j/queue/rotational;
done
#noatime.sh
#Remount all partitions with noatime, for more info visit [URL="http://forum.xda-developers.com/showpost.php?p=8708125&postcount=1"]http://forum.xda-developers.com/showpost.php?p=8708125&postcount=1[/URL]
for k in $(busybox mount | grep relatime | cut -d " " -f3)
do
sync
busybox mount -o remount,noatime $k
done
#scheduler.sh
#Changes the scheduler used by the system, for more info visit [URL="http://forum.xda-developers.com/showpost.php?p=4806456&postcount=1"]http://forum.xda-developers.com/showpost.php?p=4806456&postcount=1[/URL]
for i in `busybox ls -1 /sys/block/mtdblock*`
do
echo "noop" > $i/queue/scheduler;
done
echo "noop" > /sys/block/mmcblk0/queue/scheduler;
echo "noop" > /sys/block/dm-0/queue/scheduler;
echo "noop" > /sys/block/dm-1/queue/scheduler;
#setprop.sh (currently testing)
#various build.prop settings
setprop wifi.supplicant_scan_interval 600
These are few of the tweaks that I have tested(and using right now), I will update it every time I test something out and will eventually add some of FranciscoFranco's tweaks for you to try out.
You can get some useful scripts from here - Performance and battery tweaks - by Franciscofranco (just read along)
Note: These scripts are no different from the scripts in FranciscoFranco's thread, I just categorized each individual tweaks and separated them for you to be able to apply each one separately. I will be more inclined to describe only battery saving tweaks as I am only interested with tweaks that could extend battery life(this includes performance tweaks that doesn't seem to affect the battery behavior at all)
Here's the my initial script again: SD Tweakz v2
Here's the downloadable version of each tweak mentioned above:
non-rotational.sh
scheduler.sh
noatime.sh
setprop.sh
If anything bad happens, just flash this Undo.zip(unsigned so just toggle signature verification) and everything should be back as it was before.
Huge thanks to NervGaz for providing a solution to the mount point conflict issue and of course Franciscofranco for those lively discussions and ideas we exchange.

Awesome job, I already linked this on my first page

@Ungaze
what is the difference from Tweakz V2?

bluviper said:
@Ungaze
what is the difference from Tweakz V2?
Click to expand...
Click to collapse
almost everything. Flashing this script alone won't do anything. You need to get your tweaks from here first and save it to /sdcard/tweakz folder. reboot and this way it will do exactly what Tweakz V2 did. Now if you notice any lag or performance drop, apply each tweak/script one by one to debug/troubleshoot which one is causing it.
Additionally if you found anything useful, you can make your own script.sh and place it on the /tweakz folder to run it on every boot.

ungaze said:
almost everything. Flashing this script alone won't do anything. You need to get your tweaks from here first and save it to /sdcard/tweakz folder. reboot and this way it will do exactly what Tweakz V2 did. Now if you notice any lag or performance drop, apply each tweak/script one by one to debug/troubleshoot which one is causing it.
Additionally if you found anything useful, you can make your own script.sh and place it on the /tweakz folder to run it on every boot.
Click to expand...
Click to collapse
Yes please, keep posting feedback either here or the other thread. Anything is useful since some users say they suffer some ocasional lag, others don't notice improvements, others say their phone became super fast...

ok now i get it... so the first batch of scripts on zip cannot be run on boot...
thats why you created this...
..ok i have finally applied everything! hehehe since i love smorgasbords...
and its very hard to tell that its there.... hehehe.. seems like fine to me.
no hiccups whatsoever..
but i feel its OK... thanks again man..

ok now i get it... so the first batch of scripts on zip cannot be run on boot...
thats why you created this...
Click to expand...
Click to collapse
the first batch of scripts had to be manually moved to init.d and had to be in a specific filename with a specific header and containing all the tweaks altogether in order to run on boot.
now what I did with the update.zips(Tweakz V1, Tweakz V2) was make moving it to init.d, renaming and fixing the header all easier for you guys but it still contain all the tweaks with no option for you guys to modify/add/remove lines that you want. This time it already runs on boot.
with this tweak, everything is easily manipulated through the sd card and a simple file explorer for more flexibility and easy troubleshooting. This should also work on most phones with init.d support.
Yes please, keep posting feedback either here or the other thread.
Click to expand...
Click to collapse
And to make things neater, just post stuff regarding only this script here and everything about tweaks on the other thread mentioned above.

You don't really need to move the scripts to the data partition, just invoke the with sh, ie. "sh /sdcard/scriptz/script.sh" it would make your for loop something like this:
for script in $list
do
sh /sdcard/scriptz/$script
done
Also I'd be careful with mounting SD ahead of vold, atleast on /sdcard or /mnt/sdcard make a tempfolder somewhere as a mount point instead and you shouldn't to worry about vold throwing up on you... Just a thought.

You don't really need to move the scripts to the data partition, just invoke the with sh, ie. "sh /sdcard/scriptz/script.sh" it would make your for loop something like this:
Click to expand...
Click to collapse
didn't work last time i tried running the scripts directly from sdcard but will try it with your script.
Also I'd be careful with mounting SD ahead of vold, atleast on /sdcard or /mnt/sdcard make a tempfolder somewhere as a mount point instead and you shouldn't to worry about vold throwing up on you... Just a thought.
Click to expand...
Click to collapse
I don't really have a choice right now but to use the same method as "VOID rom" is using when loading modules. Any ideas?
BTW thanks so much

A quick and simple solution would be to just add something along the lines of
mount -o rw,remount auto /
mkdir /tmp
<mount the sdcard>
<run the scripts>
<unmount the sdcard>
rmdir /tmp
mount -o ro,remount auto /
Not the cleanest solution of all time, but it should work and no risk of conflicting mount points. Another solution is to just have people install the scripts on the /data partition in a directory there as /data is mounted rw.
Sent from my LG-P500 using Tapatalk

NervGaz said:
A quick and simple solution would be to just add something along the lines of
mount -o rw,remount auto /
mkdir /tmp
<mount the sdcard>
<run the scripts>
<unmount the sdcard>
rmdir /tmp
mount -o ro,remount auto /
Not the cleanest solution of all time, but it should work and no risk of conflicting mount points. Another solution is to just have people install the scripts on the /data partition in a directory there as /data is mounted rw.
Sent from my LG-P500 using Tapatalk
Click to expand...
Click to collapse
I was worried about the mount point traffic as well, but I guess I will be implementing the second solution instead, with a very different approach, and a more complex script.
You seem to know your trade, too bad we didn't get to collaborate before I made this script(from scratch, with no knowledge at all with scripting and how they work). Was asking and trolling on different threads with no help at all. Good thing mr. google was always there for anyone who needs help .
I'll start working and hope to hear from you about my next release as well.

You might want to look at the userinit script in the CM based ROM's around if you're going down that route, it does what you want and there's no point reinventing the wheel if you know what I mean.
Sent from my LG-P500 using Tapatalk

Great! Nice tip, never done that before. Thanks alot man.

so all in all, is this script really running on boot or not?

It runs, only problem encountered is with CM7 roms. (mount point traffic or something like that in a sense) will edit 1st page till I finish the reworked script.

Hey ungaze,I have just flashed the script and everything. I'm on CM7. What is the problem? Do I have to wait for a fix and do everything over again? Because I'm currently not experiencing any problems

Nope, it worked once, it should also work every time. Dunno which beta version of CM7 some people are having problem with. I still think this method is easier and faster for testing scripts to run on boot, but the next script will just be more lets say "compatible to a wider variety of ROMs and even other devices".

The issue can occur on rom's that mount the sdcard on /mnt/sdcard and symlink that to /sdcard as your mountpoint doesn't exist. If memory serves me right this is the correct mount procedure since 2.2 and is more in line with FHS. Potentially you can see issues with this if it mounts before vold runs as well as vold with throw an error if the mountpoint is in use. This can occur on rom's that mount to /sdcard. Hope that clears it up a bit.
Sent from my LG-P500 using Tapatalk

How does this look?
Code:
mount -o rw,remount auto /
mkdir /tmp
mount sd
mount -t vfat /dev/block/mmcblk0p1 /tmp
if [ -e /tmp/scriptz ]
then
list=`ls /tmp/scriptz/*.sh`
for script in $list
do
sh $script
done
fi
umount sd
umount /tmp
rmdir /tmp
mount -o ro,remount auto /
Also "ls /tmp/scriptz/*.sh" would show the complete path including /tmp/scriptz/------ and so I just used sh $script on line 10. is this ok?

No need to mount the sdcard in the script, vold handles all that and its not used anyway. Apart from that it looks good to me.
Sent from my LG-P500 using Tapatalk

Related

Userinit and Apps2SD for Vibrant(legacy)

NOTE: This method has been somewhat superseded by JustAnotherCrowd's method in this thread:
http://forum.xda-developers.com/showthread.php?t=744655
It should still work, however, if you don't want to mess with Odin, but if you want to use ext4 and get the max speed AND stability, I recommend using JACs method.
There are two zip files attached. Consider them "Beginner" and "Advanced". You can only use one or the other, not both. No wipe is required for either, but you will want to clean and repair your ext partition if you plan on using one.
Beginner: If you have an SD card with an ext partition on it (no swap partition, just FAT/ext), ttabal has created a fantastic script to mount it on startup. This zip file runs that script at startup. Credit to ttabbal for the script.
IMPORTANT: You will need to install the latest version of busybox before installing this update or it will not work. You can find busybox on the market for free; download and install it and then open it and click "update busybox".
http://getyourboneon.com/vibranta2sd.zip
Advanced: Enables you to place a custom userinit.sh script in /data/local (make sure premissions are set to 755) and it will run on startup.
http://getyourboneon.com/enableuserinit.zip
An explanation of how this was done:
When looking through the init.rc, I realized that there was only one thing running as root that could safely be replaced; the boot logo player. So, all this does is replace the boot logo player with a script that calls userinit.sh from /data/local and then calls the (now renamed) bootlogo player for those of you who want that nifty startup screen
A super simple (and slightly dirty) hack but I figured it might come in handy for those of us who are impatient and would like to do our own tweaks.

Nice....
I'll be looking forward to this.
Edit:
Working great.

??
Can some one elaborate on what this does?:

BM1515 said:
Can some one elaborate on what this does?:
Click to expand...
Click to collapse
http://wiki.cyanogenmod.com/index.php?title=Userinit.sh

anomalous3 said:
I found a way to get a userinit.sh script working for the vibrant for those of us who would like to run anything at startup. Already got the proof of concept working, and am now busy packaging it into an easy script that will set everything up for you. Will update this post later tonight with the finalized script once it's done.
Click to expand...
Click to collapse
Nice work. What can you do on bootup on the vibrant? I havent looked at all the kernel settings.

oh, just stuff like mounting an ext partition or initializing the modules for the FM radio (assuming we can find them and the hardware's there).

anomalous3 said:
oh, just stuff like mounting an ext partition or initializing the modules for the FM radio (assuming we can find them and the hardware's there).
Click to expand...
Click to collapse
Yes the userinit can contain quite a few script functions and technically almost all of them that would be needed on a modifed rom.
E.G
Code:
insmod /system/lib/compcache/ramzswap.ko;
rzscontrol /dev/block/ramzswap0 -i -d 32768;
busybox swapon /dev/block/ramzswap0;
echo 528000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq;
echo 0 > /proc/sys/vm/page-cluster;
# Set "deadline" scheduler fifo batch to 1 for mtdblocks and mmc
for i in `ls -1 /sys/block/mtdblock*` /sys/block/mmcblk0
do
echo 1 > $i/queue/iosched/fifo_batch
done
busybox mount -o noatime,nodiratime -t auto /dev/block/mmcblk0p2 /system/sdcard/sd;
if [ "$?" = 0 ];
then
busybox chown 1000:1000 /system/sd;
busybox chmod 771 /system/sd;
# clean up any old symlinks, create data directories
for i in dalvik-cache data;
do
if [ -h /data/$i ];
then
rm /data/$i;
fi;
if [ ! -d /data/$i ];
then
mkdir /data/$i;
busybox chown 1000:1000 /data/$i;
busybox chmod 771 /data/$i;
fi;
done;

Updated. And to mount an ext partition you'd want to mount /dev/block/mmcblk1p2.
Got my ext mounted but haven't yet figured out how to get app data over to the external sd card without tons of force closes (I'm probably setting the permissions wrong).

anomalous3 said:
Updated. And to mount an ext partition you'd want to mount /dev/block/mmcblk1p2.
Got my ext mounted but haven't yet figured out how to get app data over to the external sd card without tons of force closes (I'm probably setting the permissions wrong).
Click to expand...
Click to collapse
Those were some examples not specifically for the Vibrant.

justanothercrowd said:
Those were some examples not specifically for the Vibrant.
Click to expand...
Click to collapse
I know I could tell by the echo 528000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq;
I was just sayin' though in case anyone was interested in making this work....too tired to mess with it anymore tonight.

anomalous3 said:
Updated. And to mount an ext partition you'd want to mount /dev/block/mmcblk1p2.
Got my ext mounted but haven't yet figured out how to get app data over to the external sd card without tons of force closes (I'm probably setting the permissions wrong).
Click to expand...
Click to collapse
I've been trying to get the ext partition to mount, but I keep getting errors from mount. This is just with "adb shell". I did "su", and have root. What command are you using? Does it only work from the userinit?
# mount /dev/block/mmcblk1p2 /system/sd
Usage: mount [-r] [-w] [-o options] [-t type] device directory
# mount -t auto /dev/block/mmcblk1p2 /system/sd
mount: No such device
# ls /dev/block/mmcblk1p2
/dev/block/mmcblk1p2
The device and mount directory do exist, so I'm a bit lost. I'll give it a go with the userinit hack and see if that gets things running.
EDIT: Nevermind, I forgot to do "busybox mount". grrrrr.. that works now.
EDIT2: Ummm... it mounts as a j4fs with a bunch of crap I've never seen on there. WTF?!? I didn't even know that filesystem existed.

maybe try
Code:
busybox mount -t ext3 /dev/block/mmcblk1p1 /system/sd
? I got it to mount and recognize the ext partition, my trouble was getting the data over to it. maybe a symlink isn't the best way to do it and I could try a bind mount.....

OK. I got it working, had to use mkfs.ext2 to re-format the ext partition. I have no idea what put that other crap there, but it wasn't me and formatting doesn't seem to have bothered anything.
Here's a rough draft of my userinit.sh. I have booted with it, and it seems to work fine. No warranty, obviously. It bind mounts /data/data to a directory on the ext partition, copying files if needed. It might do with some more cleanup and safety checking, but seems to work OK for me.
Speed wise, it seems to work pretty good.
Oh, you need to create the /system/sd directory yourself. I didn't add that in the script. remount rw and "mkdir /system/sd". A root file manager should be able to handle that as well, or add it to the script.

I've never had lag on my Vibrant so the lag fixes have always confused me a bit. Screwing with the phone is what its all about though.

well I'll be damned. It works. I wonder if we'll see an improvement from moving the dalvik-cache over too, seeing as how those are the actual executables for the applications.
[edit] It seems to have killed my mobile data connection.[/edit]

anomalous3 said:
well I'll be damned. It works. I wonder if we'll see an improvement from moving the dalvik-cache over too, seeing as how those are the actual executables for the applications.
Click to expand...
Click to collapse
Possibly. I haven't tried that yet. Maybe I'll toss it on and see. I did another version that moves the mount to /sd-ext like CM5. I'll add that in here, it automated, no need to make the mount point yourself. It feels a little more "standard" to have it there.

OK. For grins, I moved dalvik-cache as well. Here's the update, same mechanism. It feels like it might be a little faster, I'm not sure. I'll let everyone have a try at it and see what you think.

it works and data works too! Also seems noticeably quicker!
With your permission, I'd like to package this into an update.zip along with the userinit enabler (once you feel it's ready) so we can have a reliable way to get apps2sd working.

so with this userinit.sh we can apply the mimocan fix, not that i have noticed a hell lot of stalling but there is somewhat stalling after a while. only to make a great phone even better.

anomalous3 said:
it works and data works too! Also seems noticeably quicker!
With your permission, I'd like to package this into an update.zip along with the userinit enabler (once you feel it's ready) so we can have a reliable way to get apps2sd working.
Click to expand...
Click to collapse
just one question... why would we need a2sd? i remember when i had my mt3g and whenever i ran any sense rom or regular rom that a2sd slows it down significantly but when i stored everything on the phone it was way smoother and its not like we dont have the space..

[REQUEST] Can someone post a guide to how to get Froyo on eMMC?

I don't want to dual-boot, even, just have a nice "normal" Nookie Froyo install on eMMC. I've seen several allude to the fact that it worked for them but no reviews of how they did it. I've backed up my 2.1 install with Clockwork so I'm not really worried about that.
TIA.

It's quite simple actually. All you need is basic knowledge of adb.
All disclaimers apply, I'm not responsible for any damage. Just know that mine is running on internal partitions. And the SD does mount too!
Before doing anything, I would recommend applying a dd from your partitions to your pc.
With, for example on mmcblk0p1 (boot) adb: dd if=/dev/block/mmcblk0p1 of=boot.img
You should do that for each partition to be safe (0p1 to 0p8).
All the following commands can be execute one after one, the separations are only there to makes things a bit more clear.
Then,
Boot to a working Nookie (NF) with your uSD fresh from burning, without any google apps, and without any uSD damaged errors.
Empty your internal system and copy uSD system over, by doing:
- adb shell mount -o remount,rw /dev/block/mmcblk1 / (---there is a space after the 1---)
- adb shell
- mkdir tmpfolder
- mount /dev/block/mmcblk0p5 tmpfolder
- cd tmpfolder
- rm -r * (---note that there is space after the r---)
- cd ..
- cp -r system/* tmpfolder (---this will take a few minutes---)
- umount tmpfolder
Click to expand...
Click to collapse
Then, you need to boot push the attached files (bottom of post) except for the 2 vold files to your boot partition: mmcblk0p1. Unzip, copy content, not zip.
You could very well replace uImage with the new Quickie overclocked uImage for froyo (see dev thread).
To push attached files to boot, do:
- mount /dev/block/mmcblk0p1 tmpfolder
- exit
- adb push [folder-containing-4-attached-files-except-vold.fstab] tmpfolder
- adb shell
- umount tmpfolder
Click to expand...
Click to collapse
I would also recommend erasing all your data. But that's up to you, if you want to keep your data on it. In any case, you can revert back with the data.img you created above . So next part you could skip, haven't tried skipping personally:
Non mandatory, but you could do:
- mount /dev/block/mmcblk0p6 tmpfolder
- cd tmpfolder
- rm -r *
- cd ..
- umount tmpfolder
Click to expand...
Click to collapse
Then you need to push vold.fstab and vold.conf (unzip volds, copy content) to system/etc
Copy vold's to system/etc:
- mount /dev/block/mmcblk0p5 tmpfolder
- exit
- adb push [folder-with-vold's] tmpfolder/etc/
- adb shell
- umount tmpfolder
- rm -r tmpfolder
- exit
Click to expand...
Click to collapse
Then shut down, remove uSD, and boot.
Again, you can choose to push the Quickie uImage, I you prefer, but the accelerometer doesn't work with it at the moment. The 950 kernel does sometimes crash on boot, but once booted is quite stable.
I think that's all folks. I could have been a bit vague at some times, but this should work. And if you made your imgs as recommended, you're bullet proof.
To revert back to initial state with img files, you need to copy files to sdcard and then dd:
- adb shell mount -o remount,rw /dev/block/mmcblk1p1 sdcard
- adb push XXX.img sdcard (--could take a few minutes--)
- dd if=XXXX.img of=/dev/block/mmcblk0pX
Click to expand...
Click to collapse
Do that for each partition.
For those who don't feel up to the task, I could make a CWR flashable zip file of all this. The only thing is, CWR dosen't boot on Nookie just yet. So you couldn't restore with a zip after the change.

[Before doing anything, I would recommend applying a dd from your partitions to your pc.
With, for example on mmcblk0p1 (boot) adb: dd if=/dev/block/mmcblk0p1 of=boot.img
You should do that for each partition to be safe (0p1 to 0p8).
[/QUOTE]
I am a little confused here. What are the names of the 7 other partitions? Thanks, Great guide btw!

See here.

Do you see improved speed and touch response running nookie from emmc?

im getting a "No such file or directory" error after "adb push [folder-with-vold's] tmpfolder/etc"
I created the directory but now it looks like i am stuck at the landscape android splash screen on boot...
any ideas? I am attempting to redo the whole process again just incase i missed something.

Sorry, there's a slash after etc.
Make sure you've copied the systen files, with "ls" inside tmpfolder where you copied system. Should be a etc folder there.
Sam

to the op: I'm not knocking you here, but do you have a basic idea of generic linux file hierarchy or operations in general? Getting a basic grasp on working with files in a linux terminal will make all of these operations make a lot more sense, since most "adb shell" commands are basic linux commands.

FastCR said:
to the op: I'm not knocking you here, but do you have a basic idea of generic linux file hierarchy or operations in general? Getting a basic grasp on working with files in a linux terminal will make all of these operations make a lot more sense, since most "adb shell" commands are basic linux commands.
Click to expand...
Click to collapse
Thanks but I don't see how that comment adds anything here.
Looks like the issue is above commands copy the actual system folder (not the contents of the folder) To the root of the partition. ls shows the folder "system" not the contents including etc. They are inside the folder but if the partition is mounted as system then the folder is redundant. Will check copying the contents and see if that helps.
Once I get it working in will post back to let others know
**** in the first block of code replace
Code:
- cp -r system tmpfolder (---this will take a few minutes---)
with
Code:
- cp -r system[B]/*[/B] tmpfolder (---this will take a few minutes---)
many thanks!

FastCR said:
to the op: I'm not knocking you here, but do you have a basic idea of generic linux file hierarchy or operations in general? Getting a basic grasp on working with files in a linux terminal will make all of these operations make a lot more sense, since most "adb shell" commands are basic linux commands.
Click to expand...
Click to collapse
Why would you go out of your way to say that? It's not constructive. As a junior member with three posts and 0 thanks after a year and a half, sharpen your teeth here at XDA before you act like a big shot.

Right thanks. Changed it.
Has it worked for you?
Sent from my HTC Desire using XDA App

samuelhalff said:
You could very well replace uImage with the new Quickie overclocked uImage for froyo (see dev thread).
Click to expand...
Click to collapse
Are you certain on this part? Last I read in that thread, Froyo needs a different minimum kernel.
UPDATE: Nevermind, I missed this updated effort.
Homer

Well, last time I checked, my NC was running at 950 on froyo with setcpu.
Check the forum. There's a nookie version of quickie. Except accelerometer doesn't work..

First, huge thanks to the second poster - great guide! Can we sticky this?
Second, yes I know what dd does, etc, I've been working with Linux for about ten years . I just don't know the ins and outs of embedded devices yet.

samuelhalff said:
Right thanks. Changed it.
Has it worked for you?
Sent from my HTC Desire using XDA App
Click to expand...
Click to collapse
yeah i was up till 4am last night but got it working. first i tried to use my existing nf sd card... bad idea. would boot from emmc to the touch android screen to begin, but could not get past. i assume it was the issue on nookdevs because wifi was not enabled. so i removed the setupwizard.apk but somehow bricked and was unable to boot from emmc. so i took the following steps to get things working properly:
1. reimage boot and system from the stock 1.0.1 images and reset the nook to stock, didnt even touch. at the intro screen i just powered it off.
2. next i took a fresh nf sdcard and run steps from your post(with the correction to copy system contents)
3. from there i had a working nf from sdcard! i did my tweaks (google apps, market fix and button remapping from nookdevs froyo tips)
i might to put together a post with a more verbose set of instructions for a one stop froyo shop but if i do i will be sure to give you credit for your contribution.
thanks again!

Hi,
Second, yes I know what dd does, etc, I've been working with Linux for about ten years . I just don't know the ins and outs of embedded devices yet.
Click to expand...
Click to collapse
Well, that's a nice contrast. I've been working on Linux/Android for about 2 months now
I should have mentioned that the NF uSD Card must be a newly burnt image, without all the nookie tips added to it. Of course, your Google framework will crash if you port it without your data.
By the way, there's a nice trick to get past the numb android interface, simply touch every corner of the screen, starting with top left and going clockwise. You'll then be sent the your home screen, and from there you'll log on to google account again.
I think the best way of doing it would to create a flashable .zip, which I'll make tonight if I find the time and if people are really interested. But don't forget CWR dosen't work on nookie for the time being. The only way back would be through adb.
So, does anyone wish to have a flashable zip of this? Or will it be a waist of time?
Sam

samuelhalff said:
Hi,
Well, that's a nice contrast. I've been working on Linux/Android for about 2 months now
I should have mentioned that the NF uSD Card must be a newly burnt image, without all the nookie tips added to it. Of course, your Google framework will crash if you port it without your data.
By the way, there's a nice trick to get past the numb android interface, simply touch every corner of the screen, starting with top left and going clockwise. You'll then be sent the your home screen, and from there you'll log on to google account again.
I think the best way of doing it would to create a flashable .zip, which I'll make tonight if I find the time and if people are really interested. But don't forget CWR dosen't work on nookie for the time being. The only way back would be through adb.
So, does anyone wish to have a flashable zip of this? Or will it be a waist of time?
Sam
Click to expand...
Click to collapse
I would love a flashable .zip. I think many others would as well.

starkruzr said:
I would love a flashable .zip. I think many others would as well.
Click to expand...
Click to collapse
Can't wait for a flashable zip. Maybe even some cm7 release candidates would make me real happy.
Sent from Nooted NookColor using XDA App

[TWEAKS][UPDATED 1/05/2011 - Flashable .zips] Performance and battery tweaks

In this thread you'll find a compilations of tweaks and settings to improve your phone's performance and battery.
It isn't a walk in the park, I'll strongly advise against trying these tweaks if you don't know what you're doing. I'm not responsible for any bricked device or any kinds of problems you may have when applying the following changes. If you don't know what you're doing then simply DON'T.
Changelog 1/05/2011:
Reverted few changes, and everything should work correctly and easily. Instructions how to delete the previous version below.
Fixed the files permissions. Now you don't have to do it manually for it to work.
Download:
Tweaks .zip
Patched libsqlite .zip:
(don't use this on andy's 2.3.3 and latest CM7 from mik 6.3 roms or you'll end in a bootloop or your phone will drain a lot of battery according to some users)
libsqlite.so
Data2ext: http://forum.xda-developers.com/showthread.php?t=1042828 (thanks ungaze).
Very important:
libsqlite.so is a patched sqlite library file to turn sync off. With that change I/O should be waaay faster during db writes and reads. It only works with 2.3.x ROMs, don't bother flashing if you're with Froyo or you'll end up with a boot loop.
Instructions:
To delete the previous versions (thanks 32bits):
If you've installed any of the previously tweaks then you'll have to roll back. You have to do the following steps (this includes every possible locations):
1. Remove /system/etc/tweaks.sh
2. Remove /system/etc/init.d/00script
3. Remove /system/etc/init.d/99a
4. Remove /system/etc/init.d/99tweaks
5. Remove /data/local.prop
6. Reboot your phone.
For the .zips:
1. Download the .zips.
2. Enter recovery.
3. Flash them.
4. Reboot.
5. Done.
Prop settings, you can add them to your build.prop or local.prop:
Code:
wifi.supplicant_scan_interval=300
windowsmgr.max_events_per_sec=260
ro.lge.proximity.delay=25
mot.proximity.delay=25
net.tcp.buffersize.default=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.wifi=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.umts=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.gprs=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.edge=4096,87380,256960,4096,16384,256960
ro.HOME_APP_ADJ=1
ro.mot.eri.losalert.delay=1000
video.accelerate.hw=1
ro.ril.disable.power.collapse=0
pm.sleep_mode=1
Don't forget to nand backup first in case something goes wrong. I'm not responsible for any problem from your part.
Thank you for your donation:
- Momaro
franciscofranco said:
Battery life increase for Dummies
Do you want some extra juice in your battery life? Does it seem that you lose your battery too fast? Then you came to the right
place.
Over the time I've gathered some information about our battery and while this isn't 100% proof (because all of us use the phone for different purposes)
I think it's most accurate:
The myth of having the lowest possible frequency on your CPU while it's asleep:
Having the lowest frequencies (122 or 248) set up, it's not good. Our phone doesn't change voltages while underclocking or overclocking (as far as I know overclocking
doesn't change voltages as well) so, and only talking about underclocking, having such a low frequency is bad for your phones battery and performance. For the battery
that's because it takes longer to wake up from sleep and the time that the cpu takes to scale from 122/248 to maximum instead of using it for processing power eats
your battery away. About the performance hit, well that's pretty obvious and it takes longer to idle up, so again, more battery drain.
Having read about this the last few days actually running in Performance Governor is pretty beneficial to your battery: it wakes up faster, it performs every task faster,
then it idles up faster. Yeah during "sleep" time having 122 frequency or 806 it's the same thing because it's not using its power for anything, it's just there idling.
In any case what I always suggest is TEST it up and see for yourself. If you don't want to run with Performance governor at least run with 480 minimum frequency, it really helps.
---
Why do you run with auto-sync, gps, wifi, 3G, firewalls, anti-virus, background apps killing your battery? That's bull****. Most of you complain that your battery doesn't last as long
as it should...well that's not ROMs fault, I've been running with CM7 buils since the first builds and I never, ever, ever had battery problems even when everyone complained. Why?
Because I'm careful. If you don't need auto-sync at that time, disable it...if you don't need gps, disable it and so on. I don't know why people leave this stuff on even when they are not
using them. Firewalls? That's bull**** as well along with anti-viruses. They eat up your resources for nothing. Same goes for background apps that eat it up. Google Maps = bull****. If
you used it go kill it after you're done with it. Same with Music app. Kill it after you've listened to your 1315618 songs. But DON'T use task killers. I can't repeat this enough, just
DON'T use them for your own sake. Same goes for 3G...just don't enable it all time if you're not using it.
No Live Wallpapers as well, nor 3D app drawers, these blow your battery away easily without you knowing how or why. Don't bother tuning your brightness down...you have a device, and
that's to be used. Why buying a mobile for 200€ and not using it's screen propely? It's there to be used, full brightness looks better, it's not by decreasing it down and hurting your
eyes that you'll get 21564561 more battery hours.
---
Do you want even more battery? Flash my tweaks along with local.prop. I'm running 2.3.3 without any modification except my tweaks + local.prop + libsqlite + LauncherPro as a launcher
(this is where most of the performance comes from).
So these are my "secrets". As you can see this is not really secret and I can easily run my device without charging for 1 day and a half, 2 days max with moderate usage.
AH there's something important. After flashing a ROM be sure to charge it to 100%, enter recovery and wipe battery stats, then reboot and only when the phone is up and running you then
unplug it.
Have fun reading, I laughed a lot while writting it
Click to expand...
Click to collapse
---------------------------------------------------------------------------------------
Different method to apply the tweaks. Make sure you thank ungaze for this script
Visit this thread for a completely new method to apply these tweaks: SD Tweakz
Code:
What does it do?
-mounts SD
-checks if "scriptz" folder exists
-copies scripts from "scriptz" folder to /data partition
-sets permission to scripts
-runs all the scripts
-deletes "scriptz" folder from /data partition
-unmounts SD
-done
P.S.- Everything is pretty clear, I won't be answering anything that is specifically stated above in my post or in the following ones.

in case u dont have root explorer
1. mount -t yaffs2 -o remount,rw /dev/block/mtdblock1 /system
2. echo 4096 > /sys/devices/virtual/bdi/179:0/read_ahead_kb
PS: u cud have integrated that read_ahead_kb in your script too..and dont u have to mount /system rw first ???
EDIT: found something !!! busybox has crontab ..Guess we can schedule the above script to execute like every half and hour or so !!!

franciscofranco said:
debug.sf.hw=1 // activates hardware acceleration
Click to expand...
Click to collapse
Lol . How is that and battery life or performance , even remotely equivalate ?

" ls -1 /sys/block/mtdblock* " u need to use cut and tr with it..DOesnt work
Here's My script :
mount -t yaffs2 -o remount,rw /dev/block/mtdblock1 /system
echo 4096 > /sys/devices/virtual/bdi/179:0/read_ahead_kb
for i in `ls -l /sys/block/mtdblock* | tr -s " "| cut -d " " -f 6`
do
echo "noop" > /sys/block/$i/queue/scheduler
done
echo "noop" > /sys/block/mmcblk0/queue/scheduler

Zerobarat1 said:
Lol . How is that and battery life or performance , even remotely equivalate ?
Click to expand...
Click to collapse
It increases performance and I'm sure a lot of people doesn't even remotely know how to activate HW acceleration.

sarfaraz1989 said:
" ls -1 /sys/block/mtdblock* " u need to use cut and tr with it..DOesnt work
Here's My script :
mount -t yaffs2 -o remount,rw /dev/block/mtdblock1 /system
echo 4096 > /sys/devices/virtual/bdi/179:0/read_ahead_kb
for i in `ls -l /sys/block/mtdblock* | tr -s " "| cut -d " " -f 6`
do
echo "noop" > /sys/block/$i/queue/scheduler
done
echo "noop" > /sys/block/mmcblk0/queue/scheduler
Click to expand...
Click to collapse
That's a variation, but my script works as well, been using it for a good while, but thanks anyway

sarfaraz1989 said:
in case u dont have root explorer
PS: u cud have integrated that read_ahead_kb in your script too..and dont u have to mount /system rw first ???
Click to expand...
Click to collapse
As far as I know there is no need to mount /system rw with any of those scripts, never did it before and always worked fine.

franciscofranco said:
build.prop edit:
windowsmsg.max_events_per_sec=60 // makes the ui more fluid and snappy
Click to expand...
Click to collapse
Are you sure it is not:
windowsmgr.max_events_per_sec
?

freddysam said:
Are you sure it is not:
windowsmgr.max_events_per_sec
?
Click to expand...
Click to collapse
Yes it is, it was a typo, thank you.

Some observations:
If you want to use "-1" option with ls, you'll need to use busybox's version. The stock ls doesn't support it.
The Linux sysfs file system (as mounted in /sys) is by design a read-write virtual file system. No need to do anything extra to play with it, other than be root.
These commands shouldn't be run from cron, they belong in some init script, perhaps /init.rc or other appropriate startup location.

My class 4 Kingston can achieve something like 40 mb/s with this tweak, but it may vary from card to card, this is just my experience.
Click to expand...
Click to collapse
with which benchmarking tool/app? Using SD tools but no apparent change.
@franciscofranco
sent you a PM

ungaze said:
with which benchmarking tool/app? Using SD tools but no apparent change.
@franciscofranco
sent you a PM
Click to expand...
Click to collapse
SD Tools indeed
First post updated with new tweaks.

cud somebody post differences before and after applying the patch..SOmebody benchmark 'em !!!

franciscofranco said:
SD Tools indeed
First post updated with new tweaks.
Click to expand...
Click to collapse
so we just add the new scripts from Ungaze?
and let the previous one as is....
using GScript, these folders are missing?
silly question but, do we need to create this folders?
-----------
and also, will this work in general for all android devices regardless of ROM?

franciscofranco said:
This thread contains some tweaks that I've found and tested myself to improve performance and battery of your ROM.
It isn't a walk in the park, I'll strongly advise you to try these tweaks if you don't know what you're doing. I'm not responsible for any bricked device or any kinds of problems you may have when applying the following changes, if you don't know what you're doing then simply DON'T.
build.prop edit:
wifi.supplicant_scan_interval=200 // interval of seconds that wifi scans for another networks
mot.proximity.delay=25 // proximity sensor tweak to make it more responsive
windowsmgr.max_events_per_sec=60 // makes the ui more fluid and snappy
debug.sf.hw=1 // activates hardware acceleration
System files tweaks using Root Explorer (paid app from the Market):
Change /sys/devices/virtual/bdi/179:0/read_ahead_kb value to 4096, it improves the reading speed from the SD card. My class 4 Kingston can achieve something like 40 mb/s with this tweak, but it may vary from card to card, this is just my experience.
I/O schedulers:
To check which scheduler is used:
Code:
adb shell
~ # cat /sys/block/mtdblock0/queue/scheduler
[noop] cfq // in this case noop scheduler was selected
To select a different scheduler:
Code:
adb shell
~ # echo "noop" > /sys/block/mtdblock0/queue/scheduler
// you can change the schedulers for all your blocks, which, more likely will be mtdblock1,2,3,4,5,6,7,8 and 9. then mmcblk0 for the SD card.
This settings won't last through reboots, so either you create a shell script to run it every reboot or you change then manually. Same applies when changing read_ahead_kb file, it resets on reboot.
This is the script I'm using to run every reboot to change the scheduler:
Code:
for i in `ls -1 /sys/block/mtdblock*`
do
echo “noop” > $i/queue/scheduler
done
echo “noop” > /sys/block/mmcblk0/queue/scheduler
#[b]new line[/b] echo "noop" > /sys/block/dm-0/queue/scheduler
EDIT: ungaze kindly sent me a bunch of shell scripts and after researching, modifying them, and testing I'll suggest you to run them to increase general performance:
Code:
DM=`ls -d /sys/block/dm*`;
MTD=`ls -d /sys/block/mtd*`;
LOOP=`ls -d /sys/block/loop*`;
RAM=`ls -d /sys/block/ram*`;
for j in $DM $MTD $LOOP $RAM;
do
echo 0 > $j/queue/rotational;
done
This one tells the kernel that all those devices are not "spinning disks" to it treats them as flash memory, because that's exactly what they are.
Code:
echo 0 > /proc/sys/vm/swappiness;
echo 10 > /proc/sys/vm/dirty_ratio;
echo 1000 > /proc/sys/vm/vfs_cache_pressure;
echo 4096 > /proc/sys/vm/min_free_kbytes;
These are tweaks to kernel Virtual Memory management.
Use GScript Lite from the market, it works fine.
If you want to know about the i/o schedulers I suggest you google it.
P.S.- Everything is pretty clear, I won't be answering anything that is specifically stated above in my post.
Click to expand...
Click to collapse
Thanks. any chance of making it flashable for us troglodytes...

bluviper said:
so we just add the new scripts from Ungaze?
and let the previous one as is....
using GScript, these folders are missing?
silly question but, do we need to create this folders?
-----------
and also, will this work in general for all android devices regardless of ROM?
Click to expand...
Click to collapse
Yes just add the scripts, don't need to mess with the previous ones.
If it says a directory was not been found don't worry about it, sometimes dm-0 is mounted, sometimes it is not, I still haven't found out when.

sarfaraz1989 said:
cud somebody post differences before and after applying the patch..SOmebody benchmark 'em !!!
Click to expand...
Click to collapse
You won't notice benchmark improvements, instead you'll notice it in the normal usage. Benchmark don't measure real life scenarios.

Omnichron said:
Thanks. any chance of making it flashable for us troglodytes...
Click to expand...
Click to collapse
I don't know how to do it I'm sorry.
EDIT: I'll have a loot at it.

to tell my experience, after installing the scripts, screen transitions is now snappy.
not like before that youll have to wait half a sec or something near that... now its instant and snappy, its cool to look at. returning to homescreen is abit faster now.
opening files on my ES explorer, unzipping etc etc. works faster now.
exploring and changing files on Root Explorer is quite faster than before.
im using LG Optimus P500....
so again my question goes... will this also work with other android phones under different ROMS?

bluviper said:
to tell my experience, after installing the scripts, screen transitions is now snappy.
not like before that youll have to wait half a sec or something near that... now its instant and snappy, its cool to look at. returning to homescreen is abit faster now.
opening files on my ES explorer, unzipping etc etc. works faster now.
exploring and changing files on Root Explorer is quite faster than before.
im using LG Optimus P500....
so again my question goes... will this also work with other android phones under different ROMS?
Click to expand...
Click to collapse
Awesome
It will probably work on most devices but most likely with some adjustments, nothing I can really predict unless taking a look over the phone and it's filesystems.

[CM7][OMFGB]Software GPS Fix | V1.5.1 - 9/25/11 | Keep the (GPS) lights on!

Hi all -
I wrote a script and created a CWM update-flashable to perform a one-line install of the CM7 GPS Fix, documented here by jwleonhart. There were some complaints about jwleonhart's install instructions; it's a bit cumbersome and not trouble-free, especially for noobs. Please read the original thread for detailed instructions on what my script does; the script exactly does jwleonhart's instructions.
NOTE: EVERY VERSION OF THIS FIX MAKES SUBTLE BUT IMPORTANT CHANGES THAT MAY IMPROVE OR DEPRESS YOUR GPS FUNCTIONALITY. UNTIL A TRUE GPS DRIVER DROPS FOR THE VIBRANT (which at this point seems very unlikely) ALL WE CAN DO IS HACK AND TWEAK. NEWER VERSIONS MAY WORK BETTER OR WORSE THAN OLDER ONES! PLEASE POST WITH YOUR EXPERIENCE USING THE VARIOUS VERSIONS OF THE FIX, AND PLEASE BE CONSTRUCTIVE/HELPFUL WITH YOUR FINDINGS!
There are three separate ways to install: CWM, CWM with no gpsd, and via shell script.
CWM Installation
The easiest way to install the GPSFix files is to download and flash Vibrant_CM7_GPSFix_V1.4-CWM-signed.zip. All files will be copied over and read/execute permissions will be properly set.
NOTE: Flashable does NOT contain AngryGPS. There are some people who have better results without it, so I'll let you install that one on your own. You can find the APK at jwleonhart's CM7 Install Guide.
OPTIONAL: There's a no-gpsd version of the CWM flashable as well - if you want to use the gpsd from your current nightly, or mix and match. The GPS driver might get better in time, and who knows if down the line the gpsd bundled with the latest nightly is better than this one, pulled from Trigger Redux#13 (CM7 Nightly#54).
Script Installation
The script is available for users who want to customize their own GPS fix. It requires an extra reboot (since you can't just run the script after installing a new nightly), but you can easily add/remove files to the script to suit your own needs. Personally, I use the script to test new versions before they go into the CWM flashable.
Attached is the zip file with all the files and the shell script you need. Just extract the folder to your SD card; then in a terminal (ADB or terminal emulator with root), run these commands:
Code:
su # if you're not already dropped into superuser status
cd /sdcard/GPSFix
bash GPSFix.sh
It will automatically copy all the files (gpsd, secgps.conf, gps.conf, 90getgps_lto) to the right places, then set permissions those files, then reboot. AngryGPSmod.apk is in there but is not installed; I suggest try the GPS fix without AngryGPS first, then install it after if you don't get good results.
Script Contents
For those interested, here's the contents of the script..
Code:
#!/system/xbin/bash
FIXFILES="/system/etc/gps.conf
/etc/init.d/90getgps_lto
/system/vendor/bin/gpsd"
REMOVEONLY="/data/gps/lto.dat
/data/gps/lto2.dat
/data/gps/svstatus.txt
/data/gps/ltoStatus.txt
/data/gps/secgps.conf
/system/bin/agpsd"
mount -o rw,remount /system
echo "==================================================="
echo "======Vibrant CM7 GPS Fix One-Command Install======"
echo "=================by strictlyrude27================="
echo ""
# Delete previous fix files
echo "Deleting previous fix files..."
for file in $FIXFILES $REMOVEONLY
do
if [ -f $file ]; then
rm $file
fi
done
# Copy new files and set permissions
echo "Copying new files over..."
for file in $FIXFILES
do
fname=$(basename $file)
cp $fname $file
chmod 0755 $file
if [ $file == "/system/vendor/bin/gpsd" ]; then
chgrp shell $file
fi
done
echo "Rebooting device.. Enjoy GPS!"
echo "Install AngryGPSmod.apk manually if you want to."
echo ""
reboot
Credits
jwleonhart - writing up the CM7 install guide
roffee - finding the original GPS Fix for CM7
jad3675 - providing original Long Term Orbital download script
PLEASE go to their threads and hit their Thanks button. They did all the heavy lifting, I just packaged up their findings and work into a simple-to-use flashable.
"If I have seen far, it is because I have stood on the shoulders of giants."
--Isaac Newton
Changelog:
Code:
V1.5.1
-- renamed init-script to overwrite CM7's implementation of V3 of this fix
-- now offering "newgpsd" variant - contains gpsd from latest CM7 nightly
-- standard zip: faster locks, but more prone to randomly quitting working
-- newgpsd variant: slower locks, but more resilient GPS indicator [color="red"] still needs testing[/color]
V1.5
-- cleaned up script
-- now keeping LTO data named lto2.dat (used to rename to lto.dat)
-- lowering threshold for lto2 refresh to 3 days
V1.4 (all variants)
-- replaced lto.dat with lto2.dat - preliminary testing indicates survival after reboot and better TTFF
-- now using us.pool.ntp.org for the time server - if you're not in the US, please adjust your gps.conf accordingly
-- gps.conf tweaks - trading accuracy for TTFF for now..
V1.3.1 (all variants)
--set permissions on downloaded lto.dat to 755 (was 644) - i couldn't get
any birds in view before, now i can lock. give this a try if 1.3 doesn't work.
V1.3 (all variants)
--removed agpsd
--added 90getgps_lto - will fetch latest long term orbit data on boot
--hopefully these changes help get REPEAT locks faster - please let us know!
V1.2CWM-nogpsd
--same as V1.2CWM, but with no gpsd. This way you can use gpsd from
the latest CM7 nightlies, or whatever nightly gpsd worked best for you.
I will start collecting gpsd files and posting them for your convenience soon!
V1.2CWM
--created CWM flashable for your convenience! performs the EXACT SAME
as the script, so if you've already run V1.2, no need to flash V1.2CWM.
But, it could be useful if you tend to flash nightlies all the time.
V1.2
--changed all file permissions to 0755 - not sure how reading .conf files
worked if there wasn't any read permission. gets me a faster lock after
applying the script.
V1.1
--fixed typo - "chmod shell" should have been "chgrp"
--removed \t, \n - was not being interpreted by shell correctly
V1
--initial release
If I helped you with your CM7 experience, please hit the Thanks Button

im about to try this

Dear all -
Script was updated to V1.2. I noticed that no read permissions were set to the .conf files; my thinking is there's no way Android could read those config files without read permissions, so they weren't even doing anything.
That said, the latest script now gives permission 0755 (rwxr-xr-x) to all files. After running the script now, I get a lock after first reboot in about 25 seconds.
You can download V1.2 and start from scratch, or just copy/paste the latest script contents into your GPSFix.sh. Or, run the following commands at a terminal (ADB or terminal emulator with root):
Code:
su
mount -o rw,remount /system
chmod 0755 /data/gps/secgps.conf
chmod 0755 /system/etc/gps.conf
chmod 0755 /system/bin/agpsd
mount -o ro,remount /system
reboot
Also, I noticed 31 downloads (and there were 20-some in the original post) but only a total of 3 Thanks.. I'm kind of addicted to the Thanks button and don't ask for donations otherwise, please push it if I help make a better CM7 experience for you

do they work with MIUI ?

chuotcontodung said:
do they work with MIUI ?
Click to expand...
Click to collapse
Should work with any CM7-based ROM; I hope someone else can confirm, though; I only run vanilla CM7 and occasionally Trigger Redux.

Any chance to make it CWM-based ?
It'd be so much nicer to drop the zip into a SD root and just run it after every nighty installation.

strictlyrude27 said:
Dear all -
Script was updated to V1.2. I noticed that no read permissions were set to the .conf files; my thinking is there's no way Android could read those config files without read permissions, so they weren't even doing anything.
That said, the latest script now gives permission 0755 (rwxr-xr-x) to all files. After running the script now, I get a lock after first reboot in about 25 seconds.
You can download V1.2 and start from scratch, or just copy/paste the latest script contents into your GPSFix.sh. Or, run the following commands at a terminal (ADB or terminal emulator with root):
Code:
mount -o rw,remount /system
chmod 0755 /data/gps/secgps.conf
chmod 0755 /system/etc/gps.conf
chmod 0755 /system/bin/agpsd
mount -o ro,remount /system
reboot
Also, I noticed 31 downloads (and there were 20-some in the original post) but only a total of 3 Thanks.. I'm kind of addicted to the Thanks button and don't ask for donations otherwise, please push it if I help make a better CM7 experience for you
Click to expand...
Click to collapse
You need to add "su" to the first line of your installation instructions

ferhanmm said:
You need to add "su" to the first line of your installation instructions
Click to expand...
Click to collapse
I assumed you would be entering the terminal with root. I'll update that in the OP though, thanks.
svladimir said:
Any chance to make it CWM-based ?
It'd be so much nicer to drop the zip into a SD root and just run it after every nighty installation.
Click to expand...
Click to collapse
I don't know how to make an update.zip, but perhaps this will be a good time to learn! I'm way better at shell scripting which is why I went this route. I'll see what I can do, hopefully I can have a CWM flashable soon.. if anyone else can help me I would much appreciate it.
That said, note that you can still open an adb shell in recovery mode, so you could run the script after you flash the nightly. I haven't tried that, but I will soon.

strictlyrude27 said:
I assumed you would be entering the terminal with root. I'll update that in the OP though, thanks.
Click to expand...
Click to collapse
Lol yea but I guarantee you that if you didn't add it more than 20 people would ask

It turns out making an update.zip isn't so hard after all testing it now, if it works out I'll upload to OP. I'll keep the original scripts and stuff for posterity's sake.

Great efforts, wow
This is just great piece of development, a sure and simple cure for the GPS and the CM 7+ roms.
Now that you have created this script, one so simple, there will be leages of Vibrant Users who will be able to take advantage of your generousity and put this puppy to work.
Kudos and once again, great work.... W.0.W.
I can confirm, with the AngryGPS I was able to lock in with fast lock in up to Accuracy of 20 feet, picked up 8 of the 12 satellites in view.
Thank you very, very much....

Dear all -
V1.2CWM released! As requested, a CWM flashable zip has been created. It does literally the exact same thing as V1.2 (copies over the GPS files to the right locations, sets 0755 permissions on all files). You don't need to flash if you've already installed V1.2, but I would keep the zip on hand for when you decide to flash a new nightly.
As always, the Thanks button lets me know I'm loved
I plan on starting a gpsd database, seems that while all gpsd's are created equal, some are more equal than others so you can mix and match the gpsd from a previous nightly, rather than referring to the supermassive black hole that is the official CM7 Nightly thread.
And finally, I must point out that I did NOT create these fixes. All the credit and praise belongs to jwleonhart and roffee. I just packaged up their work into an easy-to-install package, those guys did the real work! Please find their threads in the Credits section of my OP and hit the Thanks button!

My phone refuses to download these. Annoying.

^ try getting astro, go to preferences and allow internet downloads.
Also, chrome to phone is amazing

s15274n said:
^ try getting astro, go to preferences and allow internet downloads.
Also, chrome to phone is amazing
Click to expand...
Click to collapse
I already did the astro thing.
Turned it on and off several times.
And I used chrome to phone to send the link, with the same result.
I swtiched over to Opera, and that eventually agreed to download it.

OP updated. I now offer a no-gpsd version of the CWM flashable, in case you want to keep your gpsd or mix and match with other nightlys. I'll put up a link to a Dropbox to store GPS drivers from every nightly.
Ironically, the fix used to work for me 100% of the time, but not anymore. I'm going to start experimenting with new gpsd's from CM7 nightlies; please also let me know of your own results!
EDIT: I wasn't getting locks, or was getting and losing locks with my fix. Tried #72 gpsd and the nogpsd flash.. 0/8 birds after 5 minutes. Reflashed my own fix. TTFF [time to first fix] 17 seconds, 7/10 satellites, 150 ft accuracy. After 1 minute, 20 foot accuracy. Rebooted. 0/10 after 5 minutes.
I wish I understood you, GPS. I wish I understood you.

very nice.. i tried right now..
before this, its takes serveral minutes to get a lock.
after this patch.
first 30 secs, In View 12 satts.
1 min, get in USE 4 satts, 25 meters accuracy.
2 min, get 6 satts, 7 meters accuracy.
Very fast!
Thanks!

Nice!!! It will be much much easier now to get GPS working after nightlies. Awesome!
Sent from my SGH-T959 using XDA App

This works but great the first day but
GPS seems to not even lock in the next day.

Dattack said:
This works but great the first day but
GPS seems to not even lock in the next day.
Click to expand...
Click to collapse
tell me about it. i put the damn thing together and i'm in the same boat. It's really hit or miss for me.

[DEV-ONLY][RECOVERY]CWM 6.0.1.x Using Pseudo File System

During my time hacking on android I've discovered some nice easter eggs deep in the android platform. One such easter egg is the mounting of ext4 images directly in the init.rc script. This is a feature I have never seen used by any oems and only by one custom rom [ EDIT: and by letama in his Sony Xperia Boot Manager ]! looking at the git logs this functionality has been present since September 2010 [ commit 49b8124a1759cb8b27e0c21a1a5a54b8a81bdb19 ]. What this effectively gives us is the ability to overlay a pseudo partition layout over the top over the existing layout, thus avoiding any "Danger" of accidental bricking the device by reformatting the SDCard. This is very similar to the way archos mount the stock file system and a variation/extension on the existing methods we use for the SDE Roms.
Although the explanation assumes the use of the SD models it should be fairly straightforward to apply the the HDD models.
THE METHOD:
PART 1 - Prepare a recovery ext4 image file
1. Build CWM6 from the CM10 source.
2. Modify The Recovery's init.rc file to look something similar to this
Code:
on early-init
start ueventd
on init
export PATH /sbin
export ANDROID_ROOT /system
export ANDROID_DATA /data
export EXTERNAL_STORAGE /sdcard
symlink /system/etc /etc
mkdir /boot
mkdir /sdcard
mkdir /system
mkdir /data
mkdir /cache
mount /tmp /tmp tmpfs
mkdir /partitions 0771 system system
mount ext4 /dev/block/mmcblk0p4 /partitions
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount ext4 [email protected]/partitions/CAC /cache nosuid nodev
mount ext4 [email protected]/partitions/DATA /data nosuid nodev
mount ext4 [email protected]/partitions/SYS /system
mount ext4 [email protected]/partitions/SDCARD /sdcard nosuid nodev
mount ext4 [email protected]/partitions/BOOT /boot
on boot
ifup lo
hostname localhost
domainname localdomain
class_start default
service ueventd /sbin/ueventd
critical
service recovery /sbin/recovery
service adbd /sbin/adbd recovery
disabled
# Always start adbd on userdebug and eng builds
# In recovery, always run adbd as root.
on property:ro.debuggable=1
write /sys/class/android_usb/android0/enable 0
write /sys/class/android_usb/android0/idVendor 18D1
write /sys/class/android_usb/android0/idProduct D001
write /sys/class/android_usb/android0/functions adb
#write /sys/class/android_usb/android0/enable 1
write /sys/class/android_usb/android0/iManufacturer $ro.product.manufacturer
write /sys/class/android_usb/android0/iProduct $ro.product.model
write /sys/class/android_usb/android0/iSerial A101S_REC
#start adbd
setprop service.adb.root 1
# Restart adbd so it can run as root
on property:service.adb.root=1
write /sys/class/android_usb/android0/enable 0
restart adbd
write /sys/class/android_usb/android0/enable 1
3. Modify the etc/recovery.fstab to look like this
Code:
# mount point fstype device
/cache ext4 /dev/block/loop1
/data ext4 /dev/block/loop2
/system ext4 /dev/block/loop3
/sdcard ext4 /dev/block/loop4
4. Creating an empty ext4 image file name REC and mount it on your pc. [ 5MB should do it ]
5. Copy the contents of the built recovery/root directory to the root of your mounted image.
6. chmod init.rc , default.prop and ueventd.rc to 644 ( rw-r-r- )
7. umount the ext4 image and push it to the root of you data partition
That's stage 1 complete. Part 2 Will Follow Shortly.....
Part 2 - Make a dual boot initramfs.cpio.lzo
1. Change the name of the /data directory to /bootdata by modifying the etc/mountpoints file in the initramfs.cpio.lzo. This stops CWM getting confused when trying to un/mount the data partition
Code:
mount_name mount_dev mount_point mount_fs mount_opts volume_name error_code custom_opt
rawfs /dev/mmcblk0p1 /mnt/rawfs rawfs none 150
system /dev/mmcblk0p2 /mnt/system ext4 rw,noatime,noexec system 152
bootdata /dev/mmcblk0p4 /bootdata ext4 rw,noatime,noexec bootdata 154 crypt_compat
storage /dev/mmcblk1p1 /mnt/storage ext4 rw,noatime #storage_name# 155
storage_A80S /bootdata/media /mnt/storage bind bootdata none 155
storage_A101S /bootdata/media /mnt/storage bind bootdata none 155
storage_A101XS /bootdata/media /mnt/storage bind bootdata none 155
storage_LUDO /bootdata/media /mnt/storage bind bootdata none 155
storage_A80H /dev/hdd1 /mnt/storage ext4 rw,noatime #storage_name# 155
storage_A101H /dev/hdd1 /mnt/storage ext4 rw,noatime #storage_name# 155
usbhost_ehci /dev/storage_ehci1 /mnt/usbhost_ehci vfat rw,noatime,utf8,shortname=mixed none 156
usbhost_otg /dev/storage_otg1 /mnt/usbhost_otg vfat rw,noatime,utf8,shortname=mixed none 156
rfsext4 /dev/loop0 /new-root ext4 rw,noatime none 157
rfsext3 /dev/loop0 /new-root ext3 rw,noatime none 157
rootfs /dev/loop0 /new-root squashfs ro,cts_compat none 157
ramdisk /tmp/ramdisk /ramdisk vfat loop,rw,utf8,shortname=mixed #ramdisk_name# 158 ramdisk,ramdisk_size=256
2. Using sirduke989 dmenu initramfs you can modify the init script in the initramfs to mount /bootdata instead of /data and also add /bootdata/REC and /bootdata/BOOT to the list
of known locations , I see this a temporary measure as there are a number of other ways to enable dual ( Triple?!? ) booting
3. Flash the modified initramfs and your choice of kernel using either the recovery menu or kd_flasher, I used the 3.0.21 kernel extracted from the 4.0.24 aos file.
You should now be able to boot into CWM Recovery!
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Clearly I'm a developer not a photographer!!
Part 3 - Create rest of the "partition" images.
You should have a /partitions directory in you device root, This is what is normally mounted as your /data ( /dev/block/mmcblk0p4) and contains normal android user data e.g installed app settings databases etc. This is where I've created the reset of my Partitions which are just more ext4 images files. I did this using "dd if=/dev/zero ...." and "mke2fs -text4 ...." on the device through adb whilst booted into CWM. This saved time in pushing large empty ext4 files from my pc.
I called my image CAC ( cache ) DATA ( data ) SYS ( system ) SDCARD ( sdcard ) BOOT ( boot ) you can obviously call them what you like and place them anywhere as long as you match up the image names with those in init.rc and make sure the loop numbers are correct in the etc/recovery.fstab everything should be fine.
You can play around with the files sizes, I have an 8gb my current file sizes at the moment are
BOOT = 25MB
CAC = 500MB
DATA = 3GB
SYS = 500MB
SDCARD = 2GB
The sdcard mount point is probably worth pointing at an external sd if you have one available. I have a 32GB Class 10 that I'll probably set up.
After you've setup your psuedo partitions you should then be able to reboot into recovery, if you've done things correctly you mount output should contain the following
Code:
/dev/block/mmcblk0p4 on /partitions type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop1 on /cache type ext4 (rw,nosuid,nodev,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop2 on /data type ext4 (rw,nosuid,nodev,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop3 on /system type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop4 on /sdcard type ext4 (rw,nosuid,nodev,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop5 on /boot type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
Everything seems to function correctly, I have successful done a backup and restore of my system partition. I have also applied CWM-SuperSU.zip through install zip from sdcard. Mounting and Remounting works although I'm not sure if Mount USB Storage works yet, I didn't on linux and I've not tested on windows and finally wiping and formating was also successful.
Part 4 - Notes on setting up rom images.
Now you may of already realized normal archos images don't come as separate the /boot and /system images so work is require to split them up.
Also if you want to split the /system from the reset of a archos image your boot partition will need to be about 50MB as archos have they /bin /lib /usr directories which contains binary files that use /lib/libuClibc-*.so as it's libc which brings there root filesystem in at around 38MB.
There is a very strong case for ditching these binaries especially when using AOSP/CM based roms. My intial tests show this is possible.
Just like the recovery init.rc Similar changes have to be made to the roms init.rc
Moving Forward:
of course, there's a lot to do but I wanted to at least get this initial information out there for people to consider. I'm currently booting a Linaro 4.1.1 rom using the split partitions. I have also been working on better booting methods which is why I haven't given any details re the initramfs init script but It's fairly straight forward to adjust and adapt. I'll write up more details soon!

More Research!
As I mentioned, I've been further looking into different booting methods and I think I'm approaching what could be a workable solution that will make the Gen9 more like standard android devices
Here's some more of my findings
1. It turns out that we can dump the existing initramfs.cpio.lzo and we can use a standard android ramdisk layout as the android init will load instead of the init script that is currently being used, this also removes the need for switch root and other nonsense that archos have in there. There was one gotcha when had me stumped for about ten minutes, I needed to add "write /sys/class/leds/lcd-backlight/brightness 75" to the init.rc to turn the screen on.
2. It's possible to stop android either using adb shell stop or stopping each service zygote etc, and start CWM while android is booted. It's probably also feasible the manage booting between recovery and android using the persist properties system which should make switching between the 2 fairly easy to control without much tweaking to any binaries. Looking at other devices, namely samsung, they seem to do something similar with recovery being in the same boot.img as the standard files, they simply load a recovery.rc instead of the main init.rc, this might mean that we have to patch CWM to load the correct init.rc I've not looked at the code properly yet but It's not going to be an issue anyway as all the code is fully available, You've gotta love open source.
3. By mounting /dev/block/mmcblk0p1 to /mnt/rawfs we are still able to use abcbox, reboot_into writes to the params file in the partition to control boot switching, so we can maintain booting into sde while leaving the stock android partition in place. I was unable to get any immediate joy from kd_flasher, that maybe because we currently have the ramdisk we want to overwrite mounted as the rootfs. Again I can't imagine it being too difficult to jig this, It can probably be worked out by looking at the current recovery ramdisk scripts should kd_flasher style functionality be required at any point.
4. Most of the binaries that rely on uClibc can be recompiled against bionic without any issue, usb_modeswitch for example. If there are any closed source ones, then the dynamic linker ld-uclibc or whatever is called, ultimately symlinks back to uClibc and we can just grab the one file and place it in the /lib directory. I tested /usr/bin/lsdvd in this way and It seemed to work fine.
I've got all this going on while still leaving a stock android fully intact, which is a great fallback Just in case.... Keeping these modifications at a safe level is one of the primary goals to enable much wider use
I'll put together some examples within the next couple of days to demostrate what I'm talking about here.
I've got a Linaro 4.1.1 ( JRO03R ) which has working powervr drivers with a 3.0.21 kernel, although that's about all that's working on it at the minute.
It's more a proof of concept than anything else, The kernel would need recompiling to add tracefs functionality which is required by jellybean but using the same magic should leave the powervr drivers functioning still, If anyone's interested I can stick that up, I've foolishly deleted ( misplaced/can't remember ) the device files I used to build this.... Too many android source trees and not using git properly leads to school boy errors.
I'm currently working on an omapzoom 4.1.2 tree using the blaze_tablet device as a base, I think this may yield the best results for the archos.
I suppose one other thing to do is the fix up a stock rom to use these methods and give it CWM, that should be pretty simple to do. Although ICS is ooold and I'm really not a fan of some of archos' methods e.g booting 4 different devices off one firmware. Although to their credit they do demostrate just what possible with deviating android from it's normal standard structures.
Hopefully this has whetted your appetites, I'm pretty excited about what's possible here as I feel it brings these archos devices in line with most others.

Me Again!
Just a cheeky little update, I been trying the figure out the best approach to handle switching between android and recovery mode. In effect I kind of wanted to create a Stage 4 bootloader! because you can never have too many bootloaders LOL I certainly wanted to do a "proper" job on it and try to avoid changes to the android platform code.
While to doing research into this I found this patch to the linux kernel which the android team submitted for review, Reading the mailing list thread I don't think it's been accepted yet! It's true what they say about the Kernel Mailing List, You need to bring your A game and be sure of what your doing..
Anyways the patch add a boot-control-block driver to kernel which check for a boot flag, which is exactly what I need to make booting into alternative configuration nice and simple. I suppose it wouldn't be too difficult to chuck in support for the fastboot protocol on one of those configurations. So a CWM Shouldn't be too far off now!!!
As a little treat I've attached a recovery based ram disk if anyone what's to play, just flash it with you favourite kernel on to your sde partition. Then You can boot into recovery and set your self up a pseudo partition image layout through adb. You won't be able to be into android, obviously until you put your old initramfs back.......
This is totally unsupported.
Click to expand...
Click to collapse
I'm just chucking up for those who want to get a feel for to do so. If your uncomfortable playing around in this area then stand well back, It's not prime time yet!!!!
However Feel free to ask questions of a technical bent but If you can't get it to boot then tough luck I'm afraid for now! :laugh:
You shouldn't be able to do any damage with this be I wouldn't go selecting wipe/format etc until you've got some partition images sorted.
I've add abcbox to sbin and symlink reboot_into. It does not seem to fully reboot but It will set the boot flag which you then follow with a call to reboot, That will reboot back into CWM (sde).
Onward
EDIT: Here's the Init.rc and etc/recovery.fstab that It attempts to use.
Code:
on early-init
start ueventd
on init
export PATH /sbin
export ANDROID_ROOT /system
export ANDROID_DATA /data
export EXTERNAL_STORAGE /sdcard
symlink /system/etc /etc
mkdir /boot
mkdir /sdcard
mkdir /system
mkdir /data
mkdir /cache
mkdir /mnt
mkdir /mnt/rawfs
mount /tmp /tmp tmpfs
mkdir /partitions 0771 system system
mount ext4 /dev/block/mmcblk0p4 /partitions
mount rawfs /dev/block/mmcblk0p1 /mnt/rawfs
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount ext4 [email protected]/partitions/CAC /cache nosuid nodev
mount ext4 [email protected]/partitions/DATA /data nosuid nodev
mount ext4 [email protected]/partitions/SYS /system
mount ext4 [email protected]/partitions/SDCARD /sdcard nosuid nodev
mount ext4 [email protected]/partitions/BOOT /boot
on boot
ifup lo
hostname localhost
domainname localdomain
class_start default
service ueventd /sbin/ueventd
critical
service recovery /sbin/recovery
service adbd /sbin/adbd recovery
disabled
# Always start adbd on userdebug and eng builds
# In recovery, always run adbd as root.
on property:ro.debuggable=1
write /sys/class/android_usb/android0/enable 0
write /sys/class/android_usb/android0/idVendor 18D1
write /sys/class/android_usb/android0/idProduct D001
write /sys/class/android_usb/android0/functions adb
#write /sys/class/android_usb/android0/enable 1
write /sys/class/android_usb/android0/iManufacturer $ro.product.manufacturer
write /sys/class/android_usb/android0/iProduct $ro.product.model
write /sys/class/android_usb/android0/iSerial A101S_REC
write /sys/class/leds/lcd-backlight/brightness 75
#start adbd
setprop service.adb.root 1
# Restart adbd so it can run as root
on property:service.adb.root=1
write /sys/class/android_usb/android0/enable 0
restart adbd
write /sys/class/android_usb/android0/enable 1
Recovery.fstab
Code:
# mount point fstype device
/cache ext4 /dev/block/loop0
/data ext4 /dev/block/loop1
/system ext4 /dev/block/loop2
/sdcard ext4 /dev/block/loop3

Any words about hdd versions?

DragosP2010 said:
Any words about hdd versions?
Click to expand...
Click to collapse
I all depends how you want the structure it, What it would change is the mount point of the paritions directory. After that. everything is loop mounted and sitting on top of the existing structure.
Code:
mount ext4 /dev/block/mmcblk0p4 /partitions

Great stuff!!!!
Hey trevd,
that's fantastic... i will definitely try this CWM in a few days with my custom kernel and bootloader (mountpoint will need some tweaks as well ).
I'm very busy these days, so i gess i'll leave some longer statements to the recent developments in a few days.
Just in short... it's very pleasant to see all these open developments popping up and i really, really appreciate this kind of hacking!
Keep on your great work... you rock!!
Cheers,
scholbert

Hi Trevd,
Nice job!
I've been using the same kind of trick on my Xperia S boot manager project, recovery on loops and mount [email protected] in inits. You may want to take a look at what I did there (see my sig), it may have some use for your project.
Basically, what I do is storing multiple kernels+cpios on the regular kernel partition. I use one (trimmed down to maximize space) to handle the boot logic and cwm, and I have enough space to handle two "regular" kernels. I handle kernel switch just before they load with a small assembly loader. It works very nicely on Xperia, and it's very nice to be able to dual boot with isolated cwms. I can't remember maximum size on a g9 kernel rawfs file, but I think you could have at least enough space to have two kernels to isolate recovery.

Hey letama,
nice to read you :highfive:
letama said:
I've been using the same kind of trick on my Xperia S boot manager project, recovery on loops and mount [email protected] in inits. You may want to take a look at what I did there (see my sig), it may have some use for your project.
Click to expand...
Click to collapse
Cool stuff again...
letama said:
Basically, what I do is storing multiple kernels+cpios on the regular kernel partition. I use one (trimmed down to maximize space) to handle the boot logic and cwm, and I have enough space to handle two "regular" kernels. I handle kernel switch just before they load with a small assembly loader. It works very nicely on Xperia, and it's very nice to be able to dual boot with isolated cwms. I can't remember maximum size on a g9 kernel rawfs file, but I think you could have at least enough space to have two kernels to isolate recovery.
Click to expand...
Click to collapse
AFAIK, we got around ~30MBytes in the raws partition on our tablets so would be possible to put some more kernel+cpios here easily.
Anyway, made some experiments with my latest u-boot port for the tablet this weekend.
I was able to bring up my A80S completely from MicroSD and boot into CWM by using uImage and uInitramfs (based on trevd's CWM image).
There's also some lowlevel multiboot implemented now by using the volume keys... but i know that i use a very special setup, so this is more a proof of concept and not a suitable environment for the average user
Cheers,
scholbert

Thanks Letama + Scholbert
I'll look at all this stuff this week....As a aside, I've played around with mmcblk0p3 and given myself an mmcblk0p5 / 6 of 4MB each. I found parted to be pretty useful (read:safe) for this..... I'm dubious about playing around with the rawfs too much at this point, mainly because I don't understand it fully, yet!.
Have you guy seen this https://github.com/swetland/omap4boot ( I think it's along the line of what Scholbert been working with/on )
Like I've mentioned to ultimate goal is a solution that is "safe" for the average user and also leaves the rest of the tablet in-tact, it maybe a lofty goal but worth a shot. :good:
Thanks for the input guys!

scholbert said:
AFAIK, we got around ~30MBytes in the raws partition on our tablets so would be possible to put some more kernel+cpios here easily.
Click to expand...
Click to collapse
30 for init kernel ? That's plenty indeed! Cool!
Anyway, made some experiments with my latest u-boot port for the tablet this weekend.
I was able to bring up my A80S completely from MicroSD and boot into CWM by using uImage and uInitramfs (based on trevd's CWM image).
There's also some lowlevel multiboot implemented now by using the volume keys... but i know that i use a very special setup, so this is more a proof of concept and not a suitable environment for the average user
Click to expand...
Click to collapse
Nice job! Too bad that Archos doesn't do this on their board with a small internal switch. Would be cool for people like me with big fingers and poor soldering skills
trevd said:
I'll look at all this stuff this week....As a aside, I've played around with mmcblk0p3 and given myself an mmcblk0p5 / 6 of 4MB each. I found parted to be pretty useful (read:safe) for this..... I'm dubious about playing around with the rawfs too much at this point, mainly because I don't understand it fully, yet!.
Click to expand...
Click to collapse
Hummm... You're going to end with a full re-partitioning scheme with system and data if you continue this way . Just be careful when you recreate partitions to let the empty space at the beginning of the disk untouched, instant brick ahead if you go there...
Just in case, here is what I did with my repartition script (do you have it ?): delete p3, delete p4, re-create p3 (careful with start point, leave the hole! it should start just after p2) as extended partition, big enough to hold the new partitions, recreate p4 (same thing about the hole, it should start after p3) with what remains and then you can create p5,p6,p7 with the size you want inside p3.
Last advice: rawfs, don't touch it .
Anyway, the good thing with what I did on Xperia S is that you don't mess with rawfs and re-partition, it's just like flashing a very big SDE kernel from recovery with unmodfified sde firmware, that's all. If I find some time, I'll take a look to see if we can do the same thing here.

letama said:
Just in case, here is what I did with my repartition script (do you have it ?): delete p3, delete p4, re-create p3 (careful with start point, leave the hole! it should start just after p2) as extended partition, big enough to hold the new partitions, recreate p4 (same thing about the hole, it should start after p3) with what remains and then you can create p5,p6,p7 with the size you want inside p3.
Click to expand...
Click to collapse
Hi
Yes I have read your previous threads on the subject which provided alot of the inspiration for the work currently at hand, It is also why I am being ultra careful around the partitions
I think maybe I'm just being too clever trying too pull everything back a step into the intramfs when we can just do the old switch root method method.... It's a little messy on the inside but it will get the job done!

Well, I don't like much the switch root too, it's not a very "Android way" of doing things and make some apps not very happy with it, but yes, it will get the job done, one root for recovery, one root for firmware. And Archos stock would be difficult without switch root, they did put far too much stuff outside of system.

letama said:
Well, I don't like much the switch root too, it's not a very "Android way" of doing things and make some apps not very happy with it, but yes, it will get the job done, one root for recovery, one root for firmware. And Archos stock would be difficult without switch root, they did put far too much stuff outside of system.
Click to expand...
Click to collapse
I'm very much for the "Android Way" I believe the archos stock roms can be re-jigged as the stuff outside of the system is not required by the system, this is all stuff that is a result of the BuildRoot build system and has a dependency on uClibc.
I'm going to try and get something usable this week, can I store additional files in the rawfs partition without running into trouble?

trevd said:
I'm very much for the "Android Way" I believe the archos stock roms can be re-jigged as the stuff outside of the system is not required by the system, this is all stuff that is a result of the BuildRoot build system and has a dependency on uClibc.
Click to expand...
Click to collapse
Well, it's required. It's used inside Android, it handles audio, wifi, codecs, smb...
I'm going to try and get something usable this week, can I store additional files in the rawfs partition without running into trouble?
Click to expand...
Click to collapse
In rawfs or initramfs ? I wouldn't add any file in rawfs, it would be difficult to do and I don't know how would behave the bootloader if it sees new files there. Initramfs you're free to do whatever you want until you reach maximum size of kernel+initramfs.

trevd said:
Have you guy seen this https://github.com/swetland/omap4boot ( I think it's along the line of what Scholbert been working with/on )
Click to expand...
Click to collapse
Well kind of... while i try to stick with the MicroSD our fellow vincencb follows the omap4boot path.
He already made a port of barebox bootloader to work with this tool and pushed it to the repos.
This way you may put anything you like on the tablet's RAM by using MicroUSB for communication and file transfer.
My way is more to get a full featured u-boot and put it into a state, where it might replace stock loader.
Last step is to put it in internal eMMC... so this is also research and development for now.
trevd said:
Like I've mentioned to ultimate goal is a solution that is "safe" for the average user and also leaves the rest of the tablet in-tact, it maybe a lofty goal but worth a shot. :good:
Click to expand...
Click to collapse
Yepp that sounds like a reasonable approach.
letama said:
30 for init kernel ? That's plenty indeed! Cool!
Click to expand...
Click to collapse
To be even more precisely, there are 32512*1K blocks for the rawfs partition.
On my device there's ~12MB left...
letama said:
Nice job! Too bad that Archos doesn't do this on their board with a small internal switch. Would be cool for people like me with big fingers and poor soldering skills
Click to expand...
Click to collapse
Yeah, a real switch would be nice indeed... there's some unused testpoints giving us additional GPIO
Need to solder though...
trevd said:
I'm very much for the "Android Way" I believe the archos stock roms can be re-jigged as the stuff outside of the system is not required by the system, this is all stuff that is a result of the BuildRoot build system and has a dependency on uClibc.
Click to expand...
Click to collapse
Some stuff outside of system is quite useful and gives us something like a minimal linux ecosystem.
Very useful at console level... some tools seem to be used by the Android system as well.
trevd said:
I'm going to try and get something usable this week, can I store additional files in the rawfs partition without running into trouble?
Click to expand...
Click to collapse
Mmmh, letama maybe right with being very careful with this part of internal storage. If it get's corrupt you'll risk a brick (could be restored though by using external boot mechanism).
Anyway the best would be to mount it RW and use the kernel driver to access it... the unknown part is still the bootcode.
There's some kind of allocation table at the beginning of rawfs partition. It is yet unknown how bootcode behaves with an additional entry
Anyway, this is a real nice project and i would really appreciate to see it pushing forward.
Take your time trevd, and again thanks a lot for contribution!!
Have a nice day,
scholbert

Not to put this down in any way, but wouldn't TWRP be better for the G9? It has a full touch tablet UI, which is better than CWM's
Sent from my Galaxy Nexus using Tapatalk 2

Quinny899 said:
Not to put this down in any way, but wouldn't TWRP be better for the G9? It has a full touch tablet UI, which is better than CWM's
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
Hi Quinny
There's nothing to stop us using whatever recovery we like.... they all work the same way ( I think ) , i.e the code is compiled into a recovery binary. Unfortunately my touch screen stopped working long ago so I wouldn't really benefit

scholbert said:
To be even more precisely, there are 32512*1K blocks for the rawfs partition.
On my device there's ~12MB left...
Click to expand...
Click to collapse
Ah, yes, but there is space reserved for each file there, what I have to figure is how much is reserved for custom file (sde kernel). I don't want to have to shift the files located after custom to make room for sde kernel , it would defeat the "no-fuss/no-risk" of the method.
Anyway the best would be to mount it RW and use the kernel driver to access it... the unknown part is still the bootcode.
There's some kind of allocation table at the beginning of rawfs partition. It is yet unknown how bootcode behaves with an additional entry
Click to expand...
Click to collapse
Definitely. Re-partitioning is much safer if space is needed.

trevd said:
.... they all work the same way ( I think ) , i.e the code is compiled into a recovery binary.
Click to expand...
Click to collapse
This is a good keyword: The recovery binary itself!
Most tools inside the recovery are simply linked to busybox, which itself is a link to recovery executable.
In other words, we have some code responsable for the menu and framebuffer stuff and we have busybox.
The strings command gave me version 1.2.0. Now my question...
How to configure this part of code?
I'd like to enhance the busybox part.
Could you please provide a little to howto for a compiler run?
Will i need all that Android stuff installed...
I you have any clue, please point me in the right direction.
Lazy,
scholbert

scholbert said:
How to configure this part of code?
I'd like to enhance the busybox part.
Could you please provide a little to howto for a compiler run?
Will i need all that Android stuff installed...
Click to expand...
Click to collapse
Yes, you need full android repo. Android Build system is messy and tightly coupled, busybox is compiled with bionic (android libc), recovery is built on top of it with few android libraries links. Isolating all this "mess" would be difficult. Except disk space required, there is no big deal in getting full android repo.
I'd suggest to take a look at this, you should do the "Prepare the Build Environment" section.
I don't know how trevd built his recovery, but what I did is create a gen9 device to get proper configuration for recovery (frame buffer config, ...). You can get mine if you want, it's a little outdated (latest cwm doesn't need a specific gfx anymore, the custom one I used has been moved to upstream for instance), but it should give you a base.
To do that, you have to create an "archos" directory in cm9/device directory, then from inside it do:
Code:
git clone git://gitorious.org/archos-ics/device-g9.git gen9
Then, you need to setup the build env once. From cm9 root, you have to do that:
Code:
. build/envsetup.sh
(it setups android build environment)
then
Code:
lunch
then choose full_gen9-eng.
(it selects device target for build)
You should have something like that:
Code:
============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=4.0.4
TARGET_PRODUCT=full_gen9
TARGET_BUILD_VARIANT=eng
TARGET_BUILD_TYPE=release
TARGET_BUILD_APPS=
TARGET_ARCH=arm
TARGET_ARCH_VARIANT=armv7-a-neon
HOST_ARCH=x86
HOST_OS=linux
HOST_BUILD_TYPE=release
BUILD_ID=IMM76L
============================================
from this point, you can compile:
make -j4 recoveryimage (change j4 with the number of parallel build you want depending on your cpu).
whole recovery fs should be in out/target/product/gen9/recovery/root, with recovery command in sbin
Last, how do you want to extend it? If you want to add custom commands, take a look at cwm bootable/recovery/extendedcommands.c, it may be easier to add stuff there than in busybox.

Database Develop

welcome