Hmm
sorry guys. by now, I'm going to stop fixing this, sigh, I'm not good enough to fix this at the moment.
Can not garantee you the safety of this method but hopefully, the fantastic voodoo lagfix is coming.
Let's hope to see it soon!
I'll leave the update.zip here, if anyone who is intersted in this method, feel free.
FILE LINK :
http://www.multiupload.com/DU013PW7LW
Hi
I have made an update.zip which fixes I9000's lag.
The idea is to format the /data partition, which is the same as /dev/block/mmcblk0p2, to the EXT4 or NILFS2 File Systems.
It's worth because, at least, we don't need an external MicroSD card.
### Before getting started... ###
This method can damage your phone, so you should know what you are attempting to do. All risks are on your own. Also, I strongly recommend you to have a nandroid backup.
### It contains... ###
- absolutely pure JM2 kernel but a tiny modification of the ramdisk. It's from JM2 firmware but should be working on every ECLAIR devices. This kernel helps mounting the data partition to be mounted in every booting and the reason why this is nearly identical to the stock is because some people mind using user-built kernels for some reasons.
- an application called "sl4a" which has shell scripts inside named "EXT4_Lagfix.sh", "NILFS2_Lagfix.sh" and "Openvpn.sh".
※It will install the kernel in the process of applying update.zip so you don't need the Odin.
### More information about this kernel... ###
- As I said, the only thing I've modified is the ramdisk. In details, I've put two files, user_init.sh and user_early_init.sh which are from Unhelpful's kernel, and these files are essential for mounting the /data partition.
- The kernel is almost pure, so it uses modules.
- The user_init.sh, user_early_init.sh support user scripts are very useful. You can see the idea in below thread, OP of Unhelpful.
http://forum.xda-developers.com/showthread.php?t=762171
### About the scripts... ###
- If you touch the EXT4_Lagfix.sh script or NILFS2_Lagfix.sh, it will ask you a superuser permission, back up the entire /data folder in your /sdcard directory, and finally, reboot and do the rest works automatically.
- You can go over to the other file system whenever you want, for instance, it can be changed to the nilfs2 while you are using the ext4 FS.
- There also is a script called Openvpn.sh which will insert tun.ko module and this is for the people who want to use openvpn.
### What you need to do is... ###
- Needs busybox installed and rooted
- Make enough space in /sdcard to make the backing up process work properly.
- In order to use NILFS2 FS, a bit of studying is needed.
About nilfs2 binaries and the Gabage Collector.
go to this site
http://www.nilfs.org/
### What I want to say is...###
- I'm not actually a goot developer so the scripts must be very messy. But it works well, at least with my device.
- Unfortunately, I haven't got the going-back-to-rfs script. I'm working on it recently so if you want to restore the all fixes, you need to flash the firmware.
- Quadrant scores : NILFS2 ~ around 1300
EXT4 ~ around 1700
Do you really concern about the score? I don't. The NILFS2 is exactly what I've needed.
### What I MUST say is... ###
- Big thanks to these people!
## Tayutama -- the beautiful sl4a application is from his rom!
## Unhelpful -- used his idea to mount the /data partition. And the NILFS2 as well!
## supercurio -- He's the one who found how to flash kernels from the phone!
Also, I uploaded some useful utils.
- mkyaffs2image / unyaffs
- chcp / lscp / lssu / mkcp / rmcp
Hope this will help you guys.
So what's different between this and the voodoo lagfix? Is the the partition? I know that voodoo ext4 is /dev/block/mmcblk0p4 while this one is /dev/block/mmcblk0p2
Nice dkcldark.
Will you share your method to unpack-repack the ramdisk from a stock kernel ?
Very nice! Great job!
NeoXTC said:
So what's different between this and the voodoo lagfix? Is the the partition? I know that voodoo ext4 is /dev/block/mmcblk0p4 while this one is /dev/block/mmcblk0p2
Click to expand...
Click to collapse
Oh, I've been busy so I couldn't have a look at the voodoo lagfix. I'm gonna check it. It could be the same as mine or much better
mmcblk0p2 is equal to /data partition, BTW.
supercurio said:
Nice dkcldark.
Will you share your method to unpack-repack the ramdisk from a stock kernel ?
Click to expand...
Click to collapse
Why not? To do this, I've done a bunch of experiments and it made me get older, I think. Will write a reply or a new thread very soon.
RyanZA said:
Very nice! Great job!
Click to expand...
Click to collapse
Thanks!!
dkcldark said:
Why not? To do this, I've done a bunch of experiments and it made me get older, I think. Will write a reply or a new thread very soon.
Click to expand...
Click to collapse
Yeah, theorically it's simple, we have the smallest piece of code building the kernel so why should extracting then reinserting the ramdisk difficult ?
And there comes the difference between the theory and the practice
Congrats for your research and the result, i hope your method can be applied to any kernel including a ramdisk!
This is a major breakthrough in our Opensource Toolbox.
So do you recommend NILFS or ext4 for phones with nand disk? Just reading up a bit on nilfs and seems to create lots of checkpoints? Is it good for nand disk to be writing that much?
I'm tempted to try this tonight
NeoXTC said:
So do you recommend NILFS or ext4 for phones with nand disk? Just reading up a bit on nilfs and seems to create lots of checkpoints? Is it good for nand disk to be writing that much?
I'm tempted to try this tonight
Click to expand...
Click to collapse
Personally, I recommend the NILFS2 File system. I've searched some infomations.
NILFS2 is log-structured File System and known that it's suitable for SSD which is based on nand flash. Normally, Flash has a limited read-write times but nilfs2 tries to write to the entire space equally, and has got the smallest removing interval so the NILFS2 file system makes SSD work very nice. And a great Wear-Leveling as well.
Click to expand...
Click to collapse
I'm not a good developer, as I already said on my post, so I'm not sure it'd also be nice for SGS but it sounds good to me. Actually, I'm using NILFS2 and it's bloody fast!
How difficult would this be to adapt to the Captivate variant of the Galaxy S?
dkcldark said:
Personally, I recommend the NILFS2 File system. I've searched some infomations.
I'm not a good developer, as I already said on my post, so I'm not sure it'd also be nice for SGS but it sounds good to me. Actually, I'm using NILFS2 and it's bloody fast!
Click to expand...
Click to collapse
on which firmware do u recommend to use it?
I'm actually on JM6 but tomorrow i want to try the JM7....
(Any battery drain? )
andars05 said:
How difficult would this be to adapt to the Captivate variant of the Galaxy S?
Click to expand...
Click to collapse
It's not difficult at all.
My kernel is originally from Unhelpful's idea so, people who use his kernel will easily be able to do it. All you need is just remove the zImage and redbend_ua files in the update.zip. Every kernel which supports Unhelpful's rules about /system/etc/init.d will be OK. Or, you can simply modifiy the scripts inside.
One more, if you use Unhelpful's kernel, you don't need the modules any more.
Narcissus85 said:
on which firmware do u recommend to use it?
I'm actually on JM6 but tomorrow i want to try the JM7....
(Any battery drain? )
Click to expand...
Click to collapse
Any firmware should be OK. I'm using JM2 at the moment but I'll try the JM7 as well. So as the result, I'm going to come up with JM7-based pure kernel, although I believe there won't be big differences between JM2 and JM7.
And the battery.. I'm sorry I haven't tested it yet since I've got 4 batteries. I'm not bothered by them lol.
dkcldark said:
It's not difficult at all.
My kernel is originally from Unhelpful's idea so, people who use his kernel will easily be able to do it. All you need is just remove the zImage and redbend_ua files in the update.zip. Every kernel which supports Unhelpful's rules about /system/etc/init.d will be OK. Or, you can simply modifiy the scripts inside.
One more, if you use Unhelpful's kernel, you don't need the modules any more.
Any firmware should be OK. I'm using JM2 at the moment but I'll try the JM7 as well. So as the result, I'm going to come up with JM7-based pure kernel, although I believe there won't be big differences between JM2 and JM7.
And the battery.. I'm sorry I haven't tested it yet since I've got 4 batteries. I'm not bothered by them lol.
Click to expand...
Click to collapse
4 batteries? ahah cool i'll test it tomorrow with my only one battery! :>
thanks for ur lagfix..
mmm just another question...my english isnt so good (i'm italian)....with this "I'm going to come up with JM7-based pure kernel, although I believe there won't be big differences between JM2 and JM7." do u mean that u are going to update ur lagfix with another kernel? so another version comes out soon?
thanks...
ivan
dkcldark said:
It's not difficult at all.
My kernel is originally from Unhelpful's idea so, people who use his kernel will easily be able to do it. All you need is just remove the zImage and redbend_ua files in the update.zip. Every kernel which supports Unhelpful's rules about /system/etc/init.d will be OK. Or, you can simply modifiy the scripts inside.
One more, if you use Unhelpful's kernel, you don't need the modules any more.
Click to expand...
Click to collapse
So, I should flash unhelpfuls kernel. I then next remove the zImage and redbend_ua files from the update.zip, install it, and then run the sl4a script?
Narcissus85 said:
4 batteries? ahah cool i'll test it tomorrow with my only one battery! :>
thanks for ur lagfix..
mmm just another question...my english isnt so good (i'm italian)....with this "I'm going to come up with JM7-based pure kernel, although I believe there won't be big differences between JM2 and JM7." do u mean that u are going to update ur lagfix with another kernel? so another version comes out soon?
thanks...
ivan
Click to expand...
Click to collapse
Yes, I am. Will Just come with a new kernel. Every else is the same.
andars05 said:
So, I should flash unhelpfuls kernel. I then next remove the zImage and redbend_ua files from the update.zip, install it, and then run the sl4a script?
Click to expand...
Click to collapse
In order to reuse after modifying the update.zip, you need to sign it again. If you want to use a plain kernel, I can make it which is not a big deal.
dkcldark said:
In order to reuse after modifying the update.zip, you need to sign it again. If you want to use a plain kernel, I can make it which is not a big deal.
Click to expand...
Click to collapse
That would be most helpful! Thanks for your work! I can't wait to test it out on my captivate
Edit:
I figured out how to resign the update.zip. I'm running the sl4a script now. I'll post the results shortly.
Edit 2:
It appears to back up the data partition, but upon reboot its still rfs.
You may want to make some other modifications I've since learn are needed. Specifically, the stock init will overwrite the MBR, removing any changes you've made to the partition table, and will then write some data to mmcblk0p2 if it does not find a valid RFS filesystem. You might not even see anything wrong at first, but with enough reboots, this will eventually corrupt your reformatted /data partition.
The edit I'm using will be in my next kernel release, and is very simple - open the init binary in a hex editor, find the string "/dev/block/mmcblk0" (make sure there's a NULL after the 0 so that it's not a substring of some longer string) and replace the "m" with a NULL. Init will then fail to rewrite the partition table (because it tries to open "/dev/block/", which is a directory). Then you simply need to change the partition table - you can use exactly the same region of the disk, you won't even need to reformat, just remove the existing partition 2 and make a new partition 3 or 4. Partitions 3 or 4 won't be checked by init on reboot.
Unhelpful said:
You may want to make some other modifications I've since learn are needed. Specifically, the stock init will overwrite the MBR, removing any changes you've made to the partition table, and will then write some data to mmcblk0p2 if it does not find a valid RFS filesystem. You might not even see anything wrong at first, but with enough reboots, this will eventually corrupt your reformatted /data partition.
The edit I'm using will be in my next kernel release, and is very simple - open the init binary in a hex editor, find the string "/dev/block/mmcblk0" (make sure there's a NULL after the 0 so that it's not a substring of some longer string) and replace the "m" with a NULL. Init will then fail to rewrite the partition table (because it tries to open "/dev/block/", which is a directory). Then you simply need to change the partition table - you can use exactly the same region of the disk, you won't even need to reformat, just remove the existing partition 2 and make a new partition 3 or 4. Partitions 3 or 4 won't be checked by init on reboot.
Click to expand...
Click to collapse
I really appreciate for this information!! Just wondering about one thing.
Should I replace the "m" to NULL once in "/dev/block/mmcblk0" or its friend "/dev/block/mmcblk0p2" as well?
Unhelpful said:
You may want to make some other modifications I've since learn are needed. Specifically, the stock init will overwrite the MBR, removing any changes you've made to the partition table, and will then write some data to mmcblk0p2 if it does not find a valid RFS filesystem. You might not even see anything wrong at first, but with enough reboots, this will eventually corrupt your reformatted /data partition.
The edit I'm using will be in my next kernel release, and is very simple - open the init binary in a hex editor, find the string "/dev/block/mmcblk0" (make sure there's a NULL after the 0 so that it's not a substring of some longer string) and replace the "m" with a NULL. Init will then fail to rewrite the partition table (because it tries to open "/dev/block/", which is a directory). Then you simply need to change the partition table - you can use exactly the same region of the disk, you won't even need to reformat, just remove the existing partition 2 and make a new partition 3 or 4. Partitions 3 or 4 won't be checked by init on reboot.
Click to expand...
Click to collapse
Yeah more like curios setup.
What needs to be done in order to adapt this to the Captivate?
I deleted the zImage and redbend_ua files and resigned the zip. I tried both of the lagfix scripts included and neither one worked. It backed up /data and rebooted. It doesn't reformat the fs, and it is still rfs. There doesn't appear to be a /system/etc/init.d directory. I'm running Unhelpful's kernel (v1.2).
I'm rooted and have busybox installed.
If only supercurio can adapt your method of editing the ramdisk inside the stock kernel, it would be awesome! As he already knows how to go back to rfs! We would then have a complete fix!
Related
WARNING:
Use this on your own risk! I will not be held responsible for any failure that might be caused by using this.
"How should I know if it works? That's what beta testers are for. I only coded it."
- Linus Torvalds
What:
Yet another attempt at breaking free from RFS on the SGS phone (ie, lagfix), for Eclair, Froyo, and hopefully Gingerbread...
Which:
Supported devices are I9000 ATM. Theoretically it should work on all SGS variants, but since I only have I9000 to test on, I can't confirm this. I'd appreciate if other model owners will give it a try and report back.
Why:
KISS. I don't want to compile my own kernel or use a specific kernel (see voodoo) for my lagfix. I'd like to have a lagfix for ANY kernel out there.
z4mod is the 1st attempt in achieving that.
Another issue is standards. We don't need multiple lagfixes, all doing the same thing. One method, easy to customize and implement - thats the way to go.
How:
1. Use the online z4mod patcher to patch your kernel.
2. Download and apply one of the following update.zip files to convert your /data partition to the filesystem of your choice.
z4mod update.zip variants:
z4mod.ext2.update.zip - convert to ext2 - works on ALL kernels.
z4mod.ext3.update.zip - convert to ext3 - works only on modified kernel which supports ext3.
z4mod.ext4.update.zip - convert to ext4 - works only on modified kernel which supports ext4.
z4mod.auto.update.zip - automatically find which fs are supported by the kernel and convert to best suited - works on ALL kernels.
z4mod.rfs.update.zip - convert back to RFS - works on ALL kernels..
These update.zip files can be applied only to kernels which has been patched with z4build - a shell script which patches zImage to allow the init scripts additional non-RFS mount to each RFS partition, or with our online z4mod patcher. If the ROM you wish to install wasn't originally patched with z4build already, you can run z4build yourself on the zImage from the ROM package and put the patched zImage back to the ROM package for flashing, or use the online z4mod patcher to do it for you. It is that easy.
[NOTE:] Kernels (zImage) patched by z4build supports both mounts - RFS and non-RFS. So it doesn't change anything for users who doesn't apply z4mod.
You can also patch your z4mod scripts to enhance it's functionality, add more filesystems support, etc.
Although z4mod allows converting all the partitions from RFS to ext2/3/4, our update.zip files only convert /data - since this is ment for the 'masses'. If you feel brave enough, feel free to experiment with converting more partitions. All the sources are well documented.
Who:
z4ziggy, aka Elia Yehuda.
___
Original post [for reference]:
Although this is a half-baked project and far from complete, im introducing it to the xda community so i might get more ideas, and fix/implement more functionality, as the project advances.
z4mod is the 1st step in breaking free from RFS death grip - or at least tries to achieve this. The project adds ext3 support to a given zImage's init scripts, and creates update.zip for converting all RFS partitions and flash the patched zImage.
...thats the idea anyway.
ext4 support is planned for future official release. for testings purposes ext3 is sufficient.
sources and information can be found on my blog here: http://z4ziggy.wordpress.com
And of course, I'm not the only one interested in your measurements and conclusions
This looks really awesome, I'm loving it!
As far as the kernel patch goes, though:
Does the same kernel patch work for both 2.1 and 2.2 kernels? They seem pretty different.
Instead of requiring a linux box to patch the kernel, do you see any problems with doing the actual patching on the stock device itself? I didn't see anything in the script that should make this too difficult.
At any rate, this looks like The Solution.
love the work all 3 of you are doing with the file system on the i9000!
awesome job.
the patch is for the initscripts only - doesn't mind which kernel version. im doing my testings on Froyo 2.2 but patching should work the same on 2.1 scripts.
I hope to have some time later tonight to update the updater-script to follow all RFS partitions, and test it. ATM it works with my /cache partition only since its easy for testings (or "crashes" should i say? ).
i will update soon.
[edit]
regarding the linux part - no can do. We patch the initramfs scripts (which resides in the zImage), and i don't know of an easy way todo so from recovery mode. The easiest way is to use linux (even in a WM - you don't even need a full blown desktop, just CLI and compile tools) and patch the zImage, but i saw some Windows tools who might be able to do the same - I don't really know since i hardly use windows.
Thanks for your efforts! Keeping a close watch on this thread
z4ziggy said:
the patch is for the initscripts only - doesn't mind which kernel version. im doing my testings on Froyo 2.2 but patching should work the same on 2.1 scripts.
I hope to have some time later tonight to update the updater-script to follow all RFS partitions, and test it. ATM it works with my /cache partition only since its easy for testings (or "crashes" should i say? ).
i will update soon.
[edit]
regarding the linux part - no can do. We patch the initramfs scripts (which resides in the zImage), and i don't know of an easy way todo so from recovery mode. The easiest way is to use linux (even in a WM - you don't even need a full blown desktop, just CLI and compile tools) and patch the zImage, but i saw some Windows tools who might be able to do the same - I don't really know since i hardly use windows.
Click to expand...
Click to collapse
That's what rooting your phone is for! Just root the device, copy over all of the required binaries (arm statically linked if required, but busybox should handle 99% of what you're using in the script) and the kernel itself can be easily exacted using dd, of course.
Whole thing can be wrapped in a UI using java without too much hassle as well.
Most users aren't gonna be up to installing linux in a VM to run the script!
just replacing those scripts on your system won't do. you need to patch the initramfs and flash zImage back.
repackaging zImage with a new initramfs is not that simple. I'm using kernel_repacker todo so.
im sure there must be a better way than kernel_repacker, but until then, this is what we use
and about the Linux usage - the user would probably never use z4build script. only the update.zip. Modders, ROM creators, etc, should use z4build (or similar method to add the appropriate "mount ext3..." command to the "mount rfs", as i showed in my blog) to allow their kernel to support ext3. Simply apply z4build on any rom's zImage, and it's users can now apply the update.zip to have this rom' work with ext3.
I hope this explanation is suffice.
z4ziggy said:
just replacing those scripts on your system won't do. you need to patch the initramfs and flash zImage back.
repackaging zImage with a new initramfs is not that simple. I'm using kernel_repacker todo so.
im sure there must be a better way than kernel_repacker, but until then, this is what we use
and about the Linux usage - the user would probably never use z4build script. only the update.zip. Modders, ROM creators, etc, should use z4build (or similar method to add the appropriate "mount ext3..." command to the "mount rfs", as i showed in my blog) to allow their kernel to support ext3. Simply apply z4build on any rom's zImage, and it's users can now apply the update.zip to have this rom' work with ext3.
I hope this explanation is suffice.
Click to expand...
Click to collapse
Ah... kernel_repacker uses GCC. That would be pretty hard to port over to the SGS's stock kernel I guess.
Guess you're right then - would have to be run externally to the device. Bit of a shame since it adds to the complexity of the whole thing, still.
This does make it nice and quick to patch up any kernel at all though, which should make it much easier to keep the kernel patching up with any leaked kernels that come out!
looks like a very promising project! i liked voodoo but sadly we can not use it for 2.2 until we get the sources and it only converts the /data partition...
thanks for your work and i will be sure to check back here & on your blog soon
z4ziggy said:
Although this is a half-baked project and far from complete, im introducing it to the xda community so i might get more ideas, and fix/implement more functionality, as the project advances.
z4mod is the 1st step in breaking free from RFS death grip - or at least tries to achieve this. The project adds ext3 support to a given zImage's init scripts, and creates update.zip for converting all RFS partitions and flash the patched zImage.
...thats the idea anyway.
ext4 support is planned for future official release. for testings purposes ext3 is sufficient.
sources and information can be found on my blog here: http://z4ziggy.wordpress.com
Click to expand...
Click to collapse
Did you manage to compile ext3 or ext4 support to Froyo kernels? I only found ext2 support in them. (At least in JPK)
Another thing I see that you mount the rfs file on the device, but for me it only got mounted as vfat, so the symlinks in /bin in factoryfs.rfs were gone. (I solved this issue by adding commands to the initramfs that restore these symlinks)
ext3 is built into 2.2 kernel, i assumed the same for 2.1.
ext4 module will have to be rebuilt for each kernel, unless we build a standard kernel with ext4 support built-in, but all this will have to wait until samsung releases the sources.
[EDIT:]
Don't use the method which mounts the rfs files on the device. It uses ext2 and its obsolete already. I've only used the rfs mount on the device since it is the only way to have RFS readable as RFS and not as FAT. if your device mounted the RFS images as FAT, either:
1. you didnt use busybox mount
2. you might need to supply "-t rfs" to your mount command
z4ziggy said:
ext3 is built into 2.2 kernel, i assumed the same for 2.1.
ext4 module will have to be rebuilt for each kernel, unless we build a standard kernel with ext4 support built-in, but all this will have to wait until samsung releases the sources.
[EDIT:]
Don't use the method which mounts the rfs files on the device. It uses ext2 and its obsolete already. I've only used the rfs mount on the device since it is the only way to have RFS readable as RFS and not as FAT. if your device mounted the RFS images as FAT, either:
1. you didnt use busybox mount
2. you might need to supply "-t rfs" to your mount command
Click to expand...
Click to collapse
I know ext4 is missing, but I couldn't even get ext3 to work on JPK. (ext2 works)
for the mounts:
1. I did use busybox mount (using toolbox mount I couldn't even mount it in vfat mode)
2. I did supply -t rfs, but it told me invalid parameter
Some additions:
When I try to mount factoryfs.rfs in rfs mode it won't work (invalid argument). in vfat mode it works, but no symlinks and other rfs stuff. I can also mount it in j4fs mode, where I get some files not available in vfat mode (like param.blk or charging.jpg), the strange thing is these files are actually the same as in /mnt/.lfs
RyanZA said:
Most users aren't gonna be up to installing linux in a VM to run the script!
Click to expand...
Click to collapse
There's an easier workaround for that.
Provide instructions to:
- Copy required files to USB stick
- Download Ubuntu Live CD
- Boot from CD
- Run scripts
If you wanted to get fancy it could be prepackaged into an existing bootable CD distro with the scripts included (checking for updates when they're launched).
From what I've read, Desire owners used bootable CDs to root their phones, so it's obviously a viable option for the standard user.
Alright, that's the extent of my expertise. I'll leave you guys to sort out the real issues now!
I'm also very interested in this so subing myself to this thread.
I quite like the fact you Windows users have to use a Linux install to do it, I get a bit fed up having to find a Windows box somewhere to use Odin and Kies all the time.
RyanZA said:
Most users aren't gonna be up to installing linux in a VM to run the script!
Click to expand...
Click to collapse
Why? Surely the people wanting to do this kind of thing will be the more technical users anyway and us Linux users have to do the more difficult task of installing Windows in a VM to use the normal tools.
my ct-ng seems to be broken, my binaries doesn't execute on my SGS for some reason, so this will have to wait for tomorrow so I can investigate this further.
I need to compile the mkfs.ext3 staticly (which seems to compile fine using several different toolchains, but none works) so i can execute it from z4mod/updater-script.
dirk1978 said:
Why? Surely the people wanting to do this kind of thing will be the more technical users anyway and us Linux users have to do the more difficult task of installing Windows in a VM to use the normal tools.
Click to expand...
Click to collapse
Not true at all!
z4ziggy said:
my ct-ng seems to be broken, my binaries doesn't execute on my SGS for some reason, so this will have to wait for tomorrow so I can investigate this further.
I need to compile the mkfs.ext3 staticly (which seems to compile fine using several different toolchains, but none works) so i can execute it from z4mod/updater-script.
Click to expand...
Click to collapse
I've had so much trouble with statically compiling stuff...
We really need some kind of complete guide on all the ins and outs of statically compiling these system utilities. For a lot of them it doesnt seem to be all that straight forward...
i've a question
i've tried to mount the partitions as ext2/3 before by replacing the rfs in init.rc and recomplied the kernel and pack the zimage, but the system wont boot. it seems it wont accept any other fs other than rfs, rootfs, etc. my init.rc looks like this:
mount ext2 /dev/block/stl9 /system
so how did u simply mount them as ext3 by just changing the init.rc and recompile the kernel?
EDIT: sorry, i just tried it again and it's ok now, but not with the "||" (or) in the middle
[ROM]JPM/JP6 "GoodBye RFS" ROM 0.2 (pre rooted, pre lagfixed, extremely experimental)
This is an ultimately experimental ROM. It might break your phone, cause headaches and data loss. This is only a showcase on how a ROM (mostly) without RFS(*) would work.
(*): this is only marketing bull****. The /efs partition still uses rfs in this rom.
This ROM contains knowledge from ChainFire, newmail, RyanZA, supercurio, ykk_five, ziggy (and me). Many thanks to them.
For the people who only care about scores and such:
Quadrant: 2006
Linpack: 14.501
Result of mount command:
Code:
/dev/block/stl9 on /system type [B]ext2 [/B](ro,noatime,nodiratime,errors=continue)
/dev/block/loop2 on /data type [B]ext2 [/B](rw,noatime,nodiratime,errors=continue)
/dev/block/loop1 on /dbdata type [B]ext2 [/B](rw,noatime,nodiratime,errors=continue)
/dev/block/stl11 on /cache type [B]ext2 [/B](rw,noatime,nodiratime,errors=continue)
For the people who actually care:
What is this?
This is a highly expermiental all-in-one lagfixed and rooted ROM based on JPM and JP6.
How to install?
You don't want to install this. Seriously... But you can find the DL link somewhere in this post if you're still curious. Simply open up Odin, use the contained pit, CSC, MODEM and PDA files, check re-partition, and wait.
It hangs after flashing at the initial boot screen (this was for version 0.1. Version 0.2 should boot up faster)
Yep, because it generates a 1.5GB large file, this takes around 3-4 minutes. It might also crash (shutdown, or switch to the battery loading screen) during this time, in case you have to reboot and try again. (or switch to a rom that's not experimental)
Hey, do I have to wait every boot? (this was for version 0.1. Version 0.2 should boot up faster)
Nope, only the first and second boot, and after each factory reset. (between the first and second boot there is a factory reset because of the CSC being applied by the recovery module)
Is this rom safe?
No. Moving near a melted nuclear reactor is safer than this.
Hey, this doesn't work / All my data is wiped / etc.
You've been warned.
For the technical people:
How?
Factoryfs.rfs was converted to ext2 on the phone prior flashing, and during flashing you actually flash "/system" as ext2 instead of rfs. Dbdata is empty, and will be replaced on the first boot, and cache.rfs was also converted to ext2 (so the csc files can be loaded on first boot), but will be actually reformatted on first boot. A pre-init script takes care of the cleaning up, and creating of ext2 partitions. The /data and /dbdata partitions are actually "dual-ext2'd" so they reside in a loop device which resides in an ext2 partition. The rationale behind this is to delay the fsync's which is the major cause of the lag. I also tried to do an "only ext2 without loop device" version, but that was useless (I've even got quadrant scores below 1k(!) with it). /cache is only single ext2'd however for recovery functions to work.
Everything is done by the /sbin/fs-patch.sh script. Feel free to check it. The script logs into the /res directory, you can check whether there were any problems during mount there (if you could actually boot of course...)
Why ext2?
The ext4 module compiled from the official sources do compile, do load, mkfs.ext4 does create the partition, but when mounting the phone drops a kernel panic. Until I can find an ext4 (or ext3) module that actually works there will be ext2 used, just to demonstrate that a no-rfs solution is actually working.
Why JPM/JP6?
You can find the rationale on the multinational ROM topic. This rom is actually the lagfixed version of that rom without the extras.
DL link:
0.1: http://android.sztupy.hu/dl/SztupY_JPM_JP6_NORFS_ROM_0.1.zip (on my server. Might be slow)
0.2: http://android.sztupy.hu/dl/SztupY_JPM_JP6_NORFS_ROM_0.2.zip (on my server. Might be slow)
Differences between 0.1 and 0.2:
0.1 uses rfs on the device + ext2 on a loop
0.2 uses ext2 on both the device and on the loop. 0.2 also has a much-much faster loop file creator utility (that creates the 1.8GB file in a second), so booting times should be normal again.
0.2 has higher quadrant scores (breaks the 2k barrier), but 0.1 felt more responsive (at least for me). I don't know anything about battery usage and such.
0.2 has problems with apps from the market, that install themselves on the sdcard. Hotfix
Links:
- scripts from initramfs
Appreciate you can post more comments about the problems and performance of this experimental ROM
Thanks for the great work!
Sent from my GT-I9000 using XDA App
this is exciting
Just threw this on my Captivate(since firmwares are semi-compatible), waiting for the ext2 partition to get created, and will report back. This is pretty awesome though, good work!
Thank you, looks very-very-very cool! Flashing now.
Great work.
Sent from my GT-I9000 using XDA App
Excellent work! Can you make a version that makes the /data partition native ext2 instead of a loop device? Thanks!
Woah, great stuff, though I'm not gonna try it, sounds to dangerous. I've been using your other ROM and lovin' it, thanks!
Hey sztupy, good work man... cant wait to see the first reports...
Linpack: 14035
What?!?
anyone has any success loading this rom? i was being curious, i tried flashing on my phone, but kept restarting and looping at the initial Galaxy S GT-i9000 screen.
by the way the linpack score, is it 14035 or its just missing a decimal point? lol!
giantdroid said:
anyone has any success loading this rom? i was being curious, i tried flashing on my phone, but kept restarting and looping at the initial Galaxy S GT-i9000 screen.
by the way the linpack score, is it 14035 or its just missing a decimal point? lol!
Click to expand...
Click to collapse
Try to reflash it using Odin. That's what I did and it's running now
I'm getting 14.211 mflops in 5.9 secs
What languages are in swype ?
Does it contain romanian ?
how is the stability so far, for you that have tested it? and screw the scores. How is the feeling? any lagg? anything?
Nice one! Has anybody had any issues with /system being EXT yet? I'm guessing not, but this is going straight on my phone anyway!
EDIT: noatime,nodiratime performs a lot better than relatime btw
Why is /data on loopback on top of RFS? Seems silly!
You should have done /data as a loopback on top of /dbdata EXT2 for extreme speed! Do it!
Just installed this ROM/Kernel...
Setup and Flashing went without any hitch. The first boot was longer than usual, but as it was forewarned..so no surprises there.
I will give it a thorough test today and post the issues here, if any.
Thank you for this amazing work.
lealdud1 said:
how is the stability so far, for you that have tested it? and screw the scores. How is the feeling? any lagg? anything?
Click to expand...
Click to collapse
No Lag at at all. This is by far the ZIPPIEST ROM I have tried...(without any lag-fix installed)
I agree, screw the scores...it's the feel and the response that matters and this ROM is just great at it.
Haven't used it much but no FC or any other errors...so far, so good.
RyanZA said:
Nice one! Has anybody had any issues with /system being EXT yet? I'm guessing not, but this is going straight on my phone anyway!
EDIT: noatime,nodiratime performs a lot better than relatime btw
Why is /data on loopback on top of RFS? Seems silly!
You should have done /data as a loopback on top of /dbdata EXT2 for extreme speed! Do it!
Click to expand...
Click to collapse
I'll definatly give this rom a try when this ^ has been done and when a few more ppl have tested it without to many issues.
Thanks in advance for all your work on this rom guys, I love your other rom sztupy.
Sounds very exciting! Will probably wait until you manage to get /data as ext2 to give it a try. Still, well done with this!
will try on saturday...just to see if any further "improvement" will crop up by then
thank you sztupy for putting this out here!
****** Information *****
I will no longer develop this kernel, for the lack of development on Z4Mod source.
If you like my work you can try this kernels:
DamianGTO Ultimate Kernel
DamianGTO Steam Kernel
You can also try my tweak program:
Damian tweak
I will continue to support this tread so long its needed.
If you want to change kernel you MUST remove all lagfix first.
*****************************************
The kernels I will post here is now based with Samsungs JPX source code.
The Froyo version is 2.2.1. in this source code.
This make a big change in performance on the samsung Galaxy S.
All this kernel I make will have Zmod in them so you can use Zmod app to convert the file system to ext2.
This will make the phone lagfree and the tweak I put in these kernels will improve things and add things that not supported in stock firmware.
The first kernels I have made(DamianGTO_JPX_1A) have this:
345MB Ram.
Optimized kernel tweaks
Alter minfree strict settings.
Deadline schedueler
Support for bootanimation.zip (custom boot animation)
Initramfs from JPY kernel( So it works on all new firmware)
The kernels has two versions. 256HZ and 500HZ versions.
File system:
Ext2
Rfs
The second kernel I have made(DamianGTO_JPX_2B) have this:
346MB Ram.
300HZ
Optimized kernel tweaks.
Cleaned the kernel from unused services.
Alter minfree strict settings.
Deadline schedueler( change some settings to balance it more)
Support for bootanimation.zip (custom boot animation)
Initramfs from JPY kernel( So it works on all new firmware)
File system:
Ext2
Rfs
This kernels is also an app so you can install it without ODIN.
Make sure you are rooted and you have Busybox 1.17 installed.
Always have a backup when you install other kernels if something happens that I cant predict.
If you come from other kernels then these kernels make sure you have flashed original kernel first so you know your phone is okey.
Do to restriction on file size I cant upload it here.
So I put it on freedrive. I hope it will work.
If any have a better way to do it for free i will look into that.
DamianGTO_JPX_1A.apk is the app with both 256HZ and 500HZ kernels.
DamianGTO_JPX_2B.apk is the app with 256Hz, 300Hz and 500Hz kernels.
I will put all kernels and program on my freedrive that i will make now.
All kernels and program I make from now I will put them on my Freedrive.
Downloading from there is easy. Works both on the computer or your phone.
************** OLD NEWS ***************
The base for these kernels is samsungs jpm source file.
So its NOT based on sztupy setup/kernel.
This kernel is NOT affected by the corruption bug that Supercurio did find.
The goal is to have a clean kernel so you can use z4mod app and change the file system. It will also have some tweaks thats useful for all.
It will always be close to stock kernel, so it will be an option to stock kernel.
If you want more tweak and other stuff there is allot of other kernels.
I will make different kernels with different things in them when I do have time to test them out and be sure they are good and stable.
Z4mod has changed they way to do things and I drop old kernels and use the new way.
I also drop all support for different file system.
Ext2 is a fast file system and its stable.
Most of the other file system use to much overhead and is slower or instable.
This make the kernel smaller to
To root the phone use Z4Root(included below)
To change file system use z4mod(included below)
If you have an old kernel from me and you want to upgrade you must
convert back to rtf first.
If you come from an other custom kernel undo all tweaks and lagfix.
Do also flash an original kernel to see your phone will boot up and work.
After that you can flash one of these kernels.
All zImage_z4mod kernels has this:
342MB Ram tweak.
Optimized kernel tweaks.
Hash 3.
File system:
Ext2
Rfs
The different in the zImage_z4mod kernels is the HZ value.
Lower HZ value can make the phone to drain battery less, but can make the phone less responsive.
Higher HZ value can make the phone drain battery more, but can make the phone more responsive.
DamianGTO_v3 kernel has this:
342MB Ram tweak.
Optimized kernel tweaks(more).
Hash 3.
Alter minfree strict settings.
I/O scheduler is deadline.
Support for bootanimation.zip (custom boot animation)
File system:
Ext2
Rfs
To use custom boot animations you need to download a bootanimation.zip and put that in your data/local folder.
you can find bootanimation.zip on this site or you can go to market and look for a program that help you with that.
If you don't want to use the bootanimation.zip you just remove it from the folder and the original boot animation will be used.
I also made a custom kernel for JPU firmware(DamianGTO_JPU_v1).
This IS JPU kernel with tweaks. Its NOT based on the old JPM kernel.
If you need to root you must use this SuperOneClick root.
This JPU kernel is also patched with Z4mod.
But you need to install the latest busybox from market if you want to convert to EXT2 file system.
This kernel also support boot animations.
DamianGTO_JPU_v1 kernel has this:
339MB Ram.
Optimized kernel tweaks(more).
Alter minfree strict settings.
Support for bootanimation.zip (custom boot animation)
File system:
Ext2
Rfs
DamianGTO_JPU_v2 kernel has this:
If you downloaded this then download V1 or V3. V2 dont work right.
DamianGTO_JPU_v3 kernel has this:
339MB Ram.
Optimized kernel tweaks(more).
Alter minfree strict settings.
Deadline schedueler.
Support for bootanimation.zip (custom boot animation)
Sdcard fix when mounting it in windows so you can write to it. It will not mount like a CD anymore
File system:
Ext2
Rfs
I have made an app for the DamianGTO_JPU_V4 kernel.
This will flash the kernel WITHOUT odin
Just make sure you are rooted before you use it.
Is you dont get superuser access, restart you phone and make sure you are rooted.
This DamianGTO_JPU_V4 kernel is little more tweak on deadline scheduler.
So it should be smother.
This kernel has:
339MB Ram.
Optimized kernel tweaks(more).
Alter minfree strict settings.
Deadline schedueler(More tweak).
Support for bootanimation.zip (custom boot animation)
Sdcard fix when mounting it in windows so you can write to it. It will not mount like a CD anymore
File system:
Ext2
Rfs
I have made an app for the DamianGTO_JPY_V1 kernel.
This DamianGTO_JPY_V1 kernel has:
339MB Ram.
Optimized kernel tweaks(more).
Alter minfree strict settings.
Deadline schedueler
Support for bootanimation.zip (custom boot animation)
File system:
Ext2
Rfs
z4root-1.3.0.apk is to root the phone. use that before you convert the file system.(NEW)
z4mod.0.9.3.apk is to convert file system.
zImage_z4mod_12_01_v1_500hz.zip Is the kernel with 500HZ value.
DamianGTO_v3_300hz.zip is the kernel with bootanimation and 300hz value.
DamianGTO_JPU_v1.zip is the JPU kernel with bootanimation and some tweaks.
DamianGTO_JPU_v3.zip is the JPU kernel with bootanimation, tweaks and usb storage fix.
DamianGTO_JPU_V4.apk is the new kernel with a installer.
DamianGTO_JPY_V1.apk is the new kernel with a installer.
Thanks all that has helped me to sort out problems.
Before you try this kernel out, make sure you have a backup on you system.
How to Install it? =)
borjaag said:
How to Install it? =)
Click to expand...
Click to collapse
Use Odin to flash the kernel. Use only PDA. no pit file and no re-pertion.
Then copy the update file to the sdcard. rename it to update.zip.
Start the phone in recoverymode and applay the update file.
Before do a backup and read about this things if you dont know what it is.
Edit: this was the old way, so read the first post.
why no EXT4?! Thanks.
hacksome said:
why no EXT4?! Thanks.
Click to expand...
Click to collapse
I think ext2 do work better and its faster then ext4.
I can compile a version with ext4 for you if you want that.
I will make support for most filsystem in the new z4mod system when it works good.
Sent from GT-I9000 jpm My own kernel for z4mod and with 341MB Ram
DamianGto said:
I think ext2 do work better and its faster then ext4.
I can compile a version with ext4 for you if you want that.
I will make support for most filsystem in the new z4mod system when it works good.
Sent from GT-I9000 jpm My own kernel for z4mod and with 341MB Ram
Click to expand...
Click to collapse
z4mod should work 100% with EXT2/EXT3/EXT4/JFS filesystems already, as long as support is compiled into the kernel.
So if you use a kernel with support, it should just work.
RyanZA said:
z4mod should work 100% with EXT2/EXT3/EXT4/JFS filesystems already, as long as support is compiled into the kernel.
So if you use a kernel with support, it should just work.
Click to expand...
Click to collapse
True. But i did not enable more support;-)
My point is that the new system is out and i have to make that work.
I have seen a couple of error on that. So i wait to realese that version. Z4ziggy is looking into the errors.
But i did this kernel and using it myself right now and it works great.
Ofcorce i want the new system to work. I spend my time to figure out what's wrong, but i guess i/we will solve that soon.
Sent from GT-I9000 jpm My own kernel for z4mod and with 341MB Ram
Thx for ur great work .
Just flashed it and it seems to work great. Before that I used a normal JPM Kernel with z4mod EXT2 without any kernel tweaks
DamianGto said:
I think ext2 do work better and its faster then ext4.
I can compile a version with ext4 for you if you want that.
Click to expand...
Click to collapse
Thanks!. I am trying out ext2 and it doesn't seem bad
Thanks.
I shall try to get it better and with more system support.
Sent from my GT-I9000 using XDA App
I would like a JPA kernel with ext4 on on all partitions also system. Thanks.
Sent from my GT-I9000 using XDA App
DamianGto said:
The goal is to have a clean kernel so you can use z4mod and use the filesystem you want.
Click to expand...
Click to collapse
Is anyone trying YAFFS/YAFFS2? As far as I know it would outperform EXT4...?
mclad said:
Is anyone trying YAFFS/YAFFS2? As far as I know it would outperform EXT4...?
Click to expand...
Click to collapse
Have not seen anybody use it.
Ext4 is not the fastest system either.
Its safe and better then stock system.
Sent from my GT-I9000 using XDA App
mclad said:
Is anyone trying YAFFS/YAFFS2? As far as I know it would outperform EXT4...?
Click to expand...
Click to collapse
YAFFS2 can't be used on /data since no interface is available. Doesn't seem like it can be done on BML either, because they're a bit freaky. (It probably can be done, I have no idea how you would though, they're non-standard.)
There is no real need though, as YAFFS2 is NOT a fast filesystem. It's filesystem designed to be safe for the underlying media, and performs decently, but it's not EXT2/HFS+/UFS speed. I think. It's hard to test since it is difficult (impossible maybe?) to port.
At any rate, since /data accounts for 99% of disk I/O, it's mostly waste of time...
As to converting over other partitions besides /data, the problem is that stock clockworkmod doesn't detect it then. Going to try work on making a 'smart' clockworkmod that can detect and mount the correct filesystems.
I' am happy with EXT2, its the most fast one and not really unsave. But would be great to have it on all partitions. Or just EXT2 on /data (for speed) and EXT4 on the other partitions
I may be (probably am) WAAAAAY out of my depth here, but you might want to grab sztupy's modified CWM - the one he uses for his ULK. I believe that would achieve the results you desire.
I think...
RyanZA said:
As to converting over other partitions besides /data, the problem is that stock clockworkmod doesn't detect it then. Going to try work on making a 'smart' clockworkmod that can detect and mount the correct filesystems.
Click to expand...
Click to collapse
Well, I will be short on this one:
Ext2 is NOT a good choice, why? No counselling, so in case of a crash, the chance of filesystem is just too big. Certainly since there is no filesystem checking utility... So this IS faster but very dangerous.
Jaffs or any other flash filesystem is a bad idea too, why? Sd does wear levelling in itself, double it and you will not benefit at all. So totally useless. More on this... On google
Sent from my GT-I9000 using XDA App
harrydg said:
Well, I will be short on this one:
Ext2 is NOT a good choice, why? No counselling, so in case of a crash, the chance of filesystem is just too big. Certainly since there is no filesystem checking utility... So this IS faster but very dangerous.
Jaffs or any other flash filesystem is a bad idea too, why? Sd does wear levelling in itself, double it and you will not benefit at all. So totally useless. More on this... On google
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
That is all very theoretical, but in practical usage of EXT2 on my day to day device for months now, I have not had any issues. And this is with deliberately pulling out the battery to try and break it.
The huge need for journaling on spinning media comes from just how unsafe spinning media can be. Flash storage is inherently a lot safer, since it writes in large chunks controlled by the disk controller, rather than playing with magnets. Not to say that it's 100% safe - and no filesystem is 100% safe when crashed - but it's really not a big issue in practice. The speed benefit makes up for any theoretical data safety issues many many times over for me, personally (and there really is a large speed benefit).
Also, e2fsck appears to do a decent job at checking for errors/metadata consistency.
Ahm,
Not really, journals are used to make writes safer, if you interrupt a write, your filesystem will be inconsistent, so you could loose your entire disk. But you are right, it's not as bad as with spinning disks, but I would never recommend it as safe... There is a reason that ext3 and 4 have been developed as successor..
Ps. Sent by my phone so my responses are short..
Sent from my GT-I9000 using XDA App
harrydg said:
Ahm,
Not really, journals are used to make writes safer, if you interrupt a write, your filesystem will be inconsistent, so you could loose your entire disk. But you are right, it's not as bad as with spinning disks, but I would never recommend it as safe... There is a reason that ext3 and 4 have been developed as successor..
Ps. Sent by my phone so my responses are short..
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
Not really. Journals are just additional metadata such as 'I am about to write to block X' 'I have finished writing to block X', etc. When the system crashes, this helps the system recover and work out what it was busy doing - it's not a silver bullet that magically stops data loss. If a file was being resized, then without journals the metadata would show that the file had been resized - even though the data inside would be garbage as it wasn't written yet. In the journaled case, it's possible to tell that this has happened, and the file can be deleted instead.
So with journaling you'd end up with the old file, and without you'd end up with a corrupt file. In either case, try not to crash your system, since an out of date file can be bad too (but not as bad as a corrupt one).
At any rate, the actual chances of managing to hit the power at just the right time (between a metadata entry and actual file entry) is VERY slim on the SGS, because the MoviNAND has a capacitor backed operation queue which generally prevents this from happening in many cases.
**** EXT4 for DATA (SD) install on second post *****
I've been slowly working on our Kaiser Kernel hoping to get extra life from it. Here are the changes I made so far.
1. Updated to the latest initrd and made a few changed in the init file
2. Changed the default I/O scheduler to noop.
3. Added block data integrity support and v4 support
4. Updated the latest yaffs2 filesupport up to changes dated 1/14/2011
5. Added PM module for Qualcomm 7500 chip
Will try to add BFQ I/O scheduler and see how the performance is compared to noop.
1/29/11 ** UPDATED KERNEL for better YAFFS2 best suited for Kaiser Samsung Memory chip **
Here is the nbh. This is type2 screen and keyboard1.
Will release my latest changes and update to git (need help on this one) when stable.
Please reinstall ROM and wipe data after flashing the kernel. The changes in yaffs2 code might cause issues. You can restore your data from BACKUP after installing the ROM.
************ TO FORCE CHECKPOINT IN DATA PARTITION PLEASE DO THIS IN TERMINAL *******************
su
echo 6 > /sys/module/yaffs/parameters/yaffs_auto_checkpoint
sync
This will change auto checkpointing to 2 and create a checkpoint.
This is just temporary, the checkpoint is deleted in reboot so the commands have to be done before every reboot.
One solution is to use Gscript.apk and type the commands in Gscripts. Execute via Gscript before reboot
**** To verify if you have checkpoint in Data Partition Please do in Terminal ******
To verify if you have yaffs2 checkpoint in the data partition Type the following in terminal
su
cat /proc/yaffs
Scroll down to Device 2 "userdata"
scroll down and look for "blocks_in_checkpt" should be 1 or 2 (not 0, if it is zero then you have no checkpoint in data partition)
Update 2/7/2011
******************EXT4 FILESYSTEM FOR SD INSTALL***************
Because of bad blocks on my Kaiser, I have to give all NAND partition to install on system while installing data on SD with EXT4 filesystem. Here are the requirements:
1. An SD card with at least class 4
2. A way to partition and format your SD with FAT/ext2/Ext4 (ext2 should be as small as possible), I use Ubuntu for this.
3. Kernel with ext4 support (this will format your whole NAND partition to use system and use EXT4 on SD for Data)
Instructions:
1. FORMAT SD (I use Ubuntu DiskUtil) with FAT/ext2/EXT4, on my 8GB SD I use 7gb for FAT/8mb for ext2/1gb for EXT4 but it's your call. The most important part is that you only give the second partition (ext2) the least amount of size.
2. Download the KAISIMG.zip, extract and you will get a file KAISIMG.NBH
3. use Atools to edit accordingly with your Kaiser's screen type and keyboard (NBH is using screen 2 and keyboard 1)
4. Flash the KAISIMG.NBH
HERE IS WHERE IT GETS TRICKY!!! PLEASE FOLLOW THESE INSTRUCTIONS CAREFULLY!!!!
a. PRESS CENTER D PAD to enter ANDROID Installer
b. Choose (*) Sys on NAND
Choose (*) Data on SDCard Partition
c. Scroll Down to Install System and choose it
d. This will wipe your Existing system! Are you sure CHOOSE (YES)
e. Would you like to clear data too (Suggested) CHOOSE (NO) ***DO NOT CLEAR DATA OR THIS WILL CHANGE YOUR THIRD PARTITION TO EXT2 and will not work.
That's it. After installation reboot and you have an optimized ext4 on your SD for data. The mount options for ext4 in this kernel are:
data=writeback, barrier=0, nobh, noauto_da_alloc
Will use barrier=1 for better data security on next release, just enjoying the speed of barrier=0 for now
clemsyn said:
Will try to update our 2.6.25 kernel too if I get some space for my hard drive.
Click to expand...
Click to collapse
Yes, Clemsyn If it's not a big problem please update 2.6.25 too. Thank you.
updates kernel 2.6.25
clemsyn said:
Will try to update our 2.6.25 kernel too if I get some space for my hard drive.
Click to expand...
Click to collapse
This would be nice. Thank you
mt1976 said:
This would be nice. Thank you
Click to expand...
Click to collapse
It would take awhile though since I have to remove my 2.6.32 kernel to put 2.6.25 since I'm limited in space. Donations for a laptop HD would be appreciated
UPDATE:
1. I think one of the reasons of data failure is that YAFFS refuses to write a checkpoint for our data partition. It writes it in the system partition with no issues. The new yaffs2 (updated 1-27-11 which I will update shortly) allows forcing checkpoint so I'll try that one and see if I can create a checkpoint on our data partition.
Finally got a checkpoint in my userdata partition...instructions posted on first post, no update on yaffs needed
clemsyn said:
It would take awhile though since I have to remove my 2.6.32 kernel to put 2.6.25 since I'm limited in space. Donations for a laptop HD would be appreciated
UPDATE:
1. I think one of the reasons of data failure is that YAFFS refuses to write a checkpoint for our data partition. It writes it in the system partition with no issues. The new yaffs2 (updated 1-27-11 which I will update shortly) allows forcing checkpoint so I'll try that one and see if I can create a checkpoint on our data partition.
Click to expand...
Click to collapse
I have a 20 GB Sata laptop drive I could get to you. Used to be in a 360 and then broke the enclosure open for a hdd when the one in my laptop died. Drive works just fine, just small lol
aceoyame said:
I have a 20 GB Sata laptop drive I could get to you. Used to be in a 360 and then broke the enclosure open for a hdd when the one in my laptop died. Drive works just fine, just small lol
Click to expand...
Click to collapse
Sorry about your phone. I was hoping you could test out my new kernel. ANyways, I think yaffs2 was having issues creating a checkpoint on the data partition since yaffs was only creating a checkpoint on proper unmount (which was not done in our kaiser). The latest yaffs can make us force a checkpoint by simply typing the command in the first post and typing "Sync" on terminal automatically creates a checkpoint in data partition. I'm currently testing it now and seeing how it goes.
BTW, I'll take that donation re:HD since I can use it as an external HD and put the 2.6.25 kernel there and improve it (that is if wife permits).
clemsyn said:
Sorry about your phone. I was hoping you could test out my new kernel. ANyways, I think yaffs2 was having issues creating a checkpoint on the data partition since yaffs was only creating a checkpoint on proper unmount (which was not done in our kaiser). The latest yaffs can make us force a checkpoint by simply typing the command in the first post and typing "Sync" on terminal automatically creates a checkpoint in data partition. I'm currently testing it now and seeing how it goes.
BTW, I'll take that donation re:HD since I can use it as an external HD and put the 2.6.25 kernel there and improve it (that is if wife permits).
Click to expand...
Click to collapse
lol she's really not that strict, she just thinks my development for our devices is a waste of time. Just PM me where to send it and ill get it out to you.
aceoyame said:
lol she's really not that strict, she just thinks my development for our devices is a waste of time. Just PM me where to send it and ill get it out to you.
Click to expand...
Click to collapse
Agreed, that's what my wife thinks too I'll PM you my location
BTW, please make sure that the location of yaffs_auto_checkpoint is in /sys/module/yaffs/parameters (some ROM might have it on modules).
UPDATE:
Checkpointing is working great for me so far. Command on first post has to be executed in every reboot to create a checkpoint so typing the commands in first post before rebooting will create a checkpoint and save data partition (me thinks).
You can install Gscript and run the script before reboot
To verify if you have yaffs2 checkpoint in the data partition Type the following in terminal
su
cat /proc/yaffs
Scroll down to Device 2 "userdata"
blocks_in_checkpt should be 1 or 2 (not 0, if it is zero then you have no checkpoint in data partition)
Can anyone help adding this to the shutdown script?
I've done 5 restarts, 2 battery pulls and 2 resets, made sure data partition was checkpointed before doing so....So far data partition has been OK with no FC's or errors, no lost apps with 18mb's left in data partition The thing that surprises me is that Phone Storage size hardly changes in size in every reboots so it's good news I have a feeling we finally nailed down this data corruption issue, but only time can tell since I will shift to prolong use before doing any restarts...
I have sent a PM to scooter hoping he can help me with a shutdown script so we won't need a Gscript. So far, Gscript is doing it for me. Upong reboot, I run the script and make sure I have a checkpoint in data partiion
clemsyn said:
sent a PM to scooter hoping he can help me with a shutdown script so we won't need a Gscript. So far, Gscript is doing it for me. Upong reboot, I run the script and make sure I have a checkpoint in data partiion
Click to expand...
Click to collapse
I've got it working in a script, i have it in a script which is run on startup and then again on a successful shutdown. I'll upload a couple of updates in a bit
EDIT: I have attached 2 updates to the post, one is for cyanogenMod based builds and the other is for all other builds such as fresh froyo etc.
Clemsyn, i have the latest yaffs source compiled into the kernel, i will commit it to git in a bit. With the latest yaffs a checkpoint is created every time sync is executed which makes scripts easier!
scooter1556 said:
I've got it working in a script, i have it in a script which is run on startup and then again on a successful shutdown. I'll upload a couple of updates in a bit
EDIT: I have attached 2 updates to the post, one is for cyanogenMod based builds and the other is for all other builds such as fresh froyo etc.
Clemsyn, i have the latest yaffs source compiled into the kernel, i will commit it to git in a bit. With the latest yaffs a checkpoint is created every time sync is executed which makes scripts easier!
Click to expand...
Click to collapse
I downloaded the CM update, and it didn't enable the checkpoint, still had to enable it manually through terminal.
Testing the kernel right now however, and so far liking it.
scooter1556 said:
I've got it working in a script, i have it in a script which is run on startup and then again on a successful shutdown. I'll upload a couple of updates in a bit
EDIT: I have attached 2 updates to the post, one is for cyanogenMod based builds and the other is for all other builds such as fresh froyo etc.
Clemsyn, i have the latest yaffs source compiled into the kernel, i will commit it to git in a bit. With the latest yaffs a checkpoint is created every time sync is executed which makes scripts easier!
Click to expand...
Click to collapse
Thanks scooter, I'll try it out. I got stuck on a fake vsync and can't get out of it that I was unable to create a checkpoint and upon reboot without a checkpoint, everything was messed up. This is perfect, getting a checkpoint on startup and another in shutdown Thanks a lot.
Krazy-Killa said:
I downloaded the CM update, and it didn't enable the checkpoint, still had to enable it manually through terminal.
Testing the kernel right now however, and so far liking it.
Click to expand...
Click to collapse
That's weird! So it didn't make a checkpoint on startup? I'm running the same script and init.rc and it works fine. I did push the file with adb though, did you fix permissions after updating?
scooter1556 said:
That's weird! So it didn't make a checkpoint on startup? I'm running the same script and init.rc and it works fine. I did push the file with adb though, did you fix permissions after updating?
Click to expand...
Click to collapse
Ooooooh.... Probably not, lol. I'll do that, and edit this post with my results.
*EDIT* Ok, I feel stupid. I still had an old androidupdate.tgz file in my sdcard andboot folder, and the boot menu used it instead of the correct .tar file... Hm, that explained why my Market stopped working, lmao.
Krazy-Killa said:
Ooooooh.... Probably not, lol. I'll do that, and edit this post with my results.
*EDIT* Ok, I feel stupid. I still had an old androidupdate.tgz file in my sdcard andboot folder, and the boot menu used it instead of the correct .tar file... Hm, that explained why my Market stopped working, lmao.
Click to expand...
Click to collapse
lol, rookie error
OK, it works on boot up since I get a checkpoint 1 every boot not sure about shutdown but if scooter says it works, I bet you it works in shutdown too
Scoot, I'm going to try to do a git diff and post it here so all the changes I've made in the config will be there.
Even with that little debacle, I had 0 corruption of data, or missing apps in my /data partition, and had to reboot 4-5 times, each time I used GScript to execute the command manually before shutdown.
And camera still works. ^.^
Krazy-Killa said:
Even with that little debacle, I had 0 corruption of data, or missing apps in my /data partition, and had to reboot 4-5 times, each time I used GScript to execute the command manually before shutdown.
And camera still works. ^.^
Click to expand...
Click to collapse
That's great news and if my memory serves me right, you easily have data corruption in shutdowns and reboot. IMO, scooter's script is the best option we have for this issue and you don't have to remember to use gscript (especially from an old person like me with slight dementia Anyways, I'll continue on with my testing with this script. If it is still working after a few days, I'll try to add Namespace support, CIFFS, PPOE in our kernel.
BTW, here is my git diff and .config file. Please put it up in GIT. Thanks.
Is it possible to install Android on Kaiser without SD? Has anyone investigated bundling the /system partition with tinboot so the whole thing is installed with a single KAISIMG?
I ask because I have one Kaiser whose SD reader is broken. If I could install more than a kernel, I could try risky changes to fix the NAND driver. If I brick the phone or kill its flash, it's no big loss.
No, you can't do it now, maybe i can suggest you to look after a method do dump the nand after install and use it as kaiser image
Exactly what I was thinking, but how to negotiate the NAND into the proper size partitions? Write kernel for rom and hope you get the sizes right, or make a kernel that readjusts /system size based on install and leave remainder for /data?
PoXFreak said:
Exactly what I was thinking, but how to negotiate the NAND into the proper size partitions? Write kernel for rom and hope you get the sizes right, or make a kernel that readjusts /system size based on install and leave remainder for /data?
Click to expand...
Click to collapse
I don't think thats l1q1d idea... perhaps a complete nand dump, and reflash it to another kaiser.
The kernel and partitions must be configures before the dump...
I do intend to try, but have been distracted by Scoot's very stable kernel, and a very nice pre-beta that I'm testing on my HTC Wizards, Gandalf and Radagast.
This is possible, in fact there was a time where an empty img file was being incorporated into the NBH where on a windows NBH the system files would normally be copied. A windows NBH consists of a number of parts, I can't remember what they are all called right now, but they can all be merged using NBHmerge. I can't give you specific instructions but there's no reason why it can't be done, not sure it'll be much fun though!
n2rjt said:
I do intend to try, but have been distracted by Scoot's very stable kernel, and a very nice pre-beta that I'm testing on my HTC Wizards, Gandalf and Radagast.
Click to expand...
Click to collapse
pre-beta that you're testing on HTC What ??
daedric said:
pre-beta that you're testing on HTC What ??
Click to expand...
Click to collapse
HTC Wizard. I have two of them, which I have named Radagast and Gandalf. It's my all-time favorite smartphone, although it is obviously even more obsolete than the Kaiser. I use one of them as my primary phone whenever Android is giving me fits. Right now I'm testing H3r7 beta 2 preview where the cook has adeptly squeezed WM6.5 into a tiny, fast, stable package.
If I knew that I wouldn't have given my Wizard away...
I thought Ham3r was finished when he hit 6.1 but I stand corrected...pfft.
help androidinstall.tgz
please share for me : file androidinstall.tgz 2.1 or 2.2 but must run wifi and 3G.
Send for me by: [email protected] thanks i come from VietNam
I think with the proper memory map Android could be installed via FrankenKaiser or something of that sort. Something that addresses the NAND directly through OEMSBL, bypassing the need for a HardSPL. Of course the phone would have to be CID unlocked to do this, but I think it's possible to install via CustomRUU if the mapping was done beforehand.
I have read somewhere that NAND marked as bad in the map still gets "written" to, meaning whatever is supposed to go there is put there and never read. Once unmarked the written info comes back, but that requires a full format anyway.
I say very possible...
I have stopped trying to do this, but wanted to record my latest thoughts in case someone reads this in the future.
I think the best way to install Android on a Kaiser that can't read its sdcard is to edit the initrd then use recovery mode:
* install adbd so it gets started in recovery mode
* allow the menu when sdcard is not installed
* change scripts to look for /data/andboot
* change recovery mode to mount /data partition to usb
Then, of course, you boot the kernel, use the menu, enter recovery mode, transfer androidinstall.tgz and androidupdate.tgz to /data/andboot, then install system, install updates, clear data, and run. If something doesn't work, adb shell or adb push can help.
I think it's too much work to be worth it on this old phone.