Anybody know what file system the (untouched) Nexus S might be rocking? RFS?
no.........
demo23019 said:
no.........
Click to expand...
Click to collapse
Is that "no" as in "nobody knows," or is it "no" as in "it is not RFS"?
no its not sporting RFS
Its completely stock 2.3 samsung has no involvement in software
Aqua1ung said:
Is that "no" as in "nobody knows," or is it "no" as in "it is not RFS"?
Click to expand...
Click to collapse
A rep from Google already said, they are using ext4.
http://forum.xda-developers.com/showpost.php?p=9627089&postcount=49
If it's not RFS then I guess the dream of Gingerbread being easily ported to other Galaxy S phones is dead. At least I think that's the case.
Dougefresh91 said:
If it's not RFS then I guess the dream of Gingerbread being easily ported to other Galaxy S phones is dead. At least I think that's the case.
Click to expand...
Click to collapse
Why? We already have Voodoo, that does the same thing in Froyo. The way the Nexus S is set up in terms of filesystem is very similar to the way a Galaxy S running Voodoo is set up. There are some differences in how the partitions are set up and yaffs being used on /cache. But the overall differences very small, and minor changes in the init scripts on the ramdisk packed in the kernel will take care of all the mounting.
I have my Vibrant converted to ext4 with the Obsidian ROM, but that only changes a partition as far as I know, not the whole phones data. Not sure about VooDoo as it would never work on my device.
Some people have been speculating that it'd be easy to get a Nexus S ROM ported over since they're both on T-Mob. I was assuming that since the file systems are different that this isn't the case. Look at how much trouble they're having getting the Cyanogen Mod working on the Vibrant.
Believe me, I'd love it if it really is a simple process for devs, but I have a feeling that that's not going to be the case. Again, I'm just speculating, I'm no dev.
I don't think it will be that difficult, because file systems can be changed - indeed, there are already lagfix kernels for the Galaxy S which eliminate the use of RFS entirely. Provided the kernel has support for ext4, the partition can just be formatted that way and mounted appropriately.
I hope you're right. If so then there's no reason at all for me to trade in my Vibrant for the NS. Lord only knows when Samsung will get it's act together concerning updates, so I think this is my only hope of ever seeing Gingerbread on this phone.
rajendra82 said:
Why? We already have Voodoo, that does the same thing in Froyo. The way the Nexus S is set up in terms of filesystem is very similar to the way a Galaxy S running Voodoo is set up. There are some differences in how the partitions are set up and yaffs being used on /cache. But the overall differences very small, and minor changes in the init scripts on the ramdisk packed in the kernel will take care of all the mounting.
Click to expand...
Click to collapse
YAFFS/YAFFS2 and JFFS etc are flash file systems. Not file systems for operating systems. You still require ext/rfs/fat32 etc for the OS to work with. They mount on a yaffs/etc partition so ext/etc do not have to worry about the intricacies of flash.
Voodoo confused a lot of things for a lot of people.
SpeeDemon said:
YAFFS/YAFFS2 and JFFS etc are flash file systems. Not file systems for operating systems. You still require ext/rfs/fat32 etc for the OS to work with. They mount on a yaffs/etc partition so ext/etc do not have to worry about the intricacies of flash.
Voodoo confused a lot of things for a lot of people.
Click to expand...
Click to collapse
Not to offend you, but you only have little knowledge, and that is a dangerous thing. There is no such distinction as file system for operating system versus flash file system. Linux kernel supports a variety of file systems. Some file systems are optimized and written specifically for flash media (e.g., YAFFS2), some are written for hard drives but could work on flash media too (e.g., fat32, ext4, jfs), some are only suitable for disk based media. The operating system partition can be mounted on any partition with a file system that the kernel recognizes. Ext2/Ext3/Ext4 have been the native file systems of Linux, but there have been a lot of machines with no use of any of them. It is up to the root user to choose what the file system of any partition is. The init script in the ramdisk packed with kernel calls the commands to mount the file systems. All Voodoo lag fix did was to convert some of the partitions mounted as RFS out of the box to ext4, and then allowed them to be mounted natively at boot time. The end result is nearly the same approach being taken by Google in the Nexus S out of the box. One of the differences in how the Nexus S or a Galaxy S running the latest Voodoo is set up is the /cache partition, which is set up as ext4 by default on Voodoo+ Galaxy S, and yaffs2 on the Nexus S. Both partitions are on flash media, but since the chip used in Galaxy S does wear leveling in the firmware, we can't use yaffs2 on /cache. Voodoo might have confused some people, but it sounds like you were confused well before that came out.
rajendra82 said:
Not to offend you, but you only have little knowledge, and that is a dangerous thing. There is no such distinction as file system for operating system versus flash file system. Linux kernel supports a variety of file systems. Some file systems are optimized and written specifically for flash media (e.g., YAFFS2), some are written for hard drives but could work on flash media too (e.g., fat32, ext4, jfs), some are only suitable for disk based media. The operating system partition can be mounted on any partition with a file system that the kernel recognizes. Ext2/Ext3/Ext4 have been the native file systems of Linux, but there have been a lot of machines with no use of any of them. It is up to the root user to choose what the file system of any partition is. The init script in the ramdisk packed with kernel calls the commands to mount the file systems. All Voodoo lag fix did was to convert some of the partitions mounted as RFS out of the box to ext4, and then allowed them to be mounted natively at boot time. The end result is nearly the same approach being taken by Google in the Nexus S out of the box. One of the differences in how the Nexus S or a Galaxy S running the latest Voodoo is set up is the /cache partition, which is set up as ext4 by default on Voodoo+ Galaxy S, and yaffs2 on the Nexus S. Both partitions are on flash media, but since the chip used in Galaxy S does wear leveling in the firmware, we can't use yaffs2 on /cache. Voodoo might have confused some people, but it sounds like you were confused well before that came out.
Click to expand...
Click to collapse
Except that ext4 support didn't exist in the .29 kernel used in Android 2.1 - you seem to think it magically just works, because it works.
SpeeDemon said:
Except that ext4 support didn't exist in the .29 kernel used in Android 2.1 - you seem to think it magically just works, because it works.
Click to expand...
Click to collapse
I know that supercurio patched in native ext4 support in Eclair, and it didn't just magically appear. The Froyo kernels do support ext4 natively though, so a simple script injection enables Voodoo. Since Gingerbread kernels from Google will also suport it (as Nexus S will actually use it), why can't another script injection work again to enable a Gingerbread kernel to work with Galaxy S.
Am I right in thinking that supercurio is a dev?
bedalus said:
Am I right in thinking that supercurio is a dev?
Click to expand...
Click to collapse
You do know this thread is more than a couple of months old, right?
Anyway, to answer your question: yes, supercurio is a dev.
Sent from my Nexus S using Tapatalk
Related
So I was a little bored this evening and wanted to mess around.
bml5 contains JUST the Linux kernel (zImage) and wanted to see what I could make it do.
Messing up this block device (/dev/block/bml5) won't actually hinder your ability to reflash with odin. messing up bml1 and 2 will though - those are boot and Sbl.
I grabbed this rom from http://forum.xda-developers.com/showpost.php?p=10040444&postcount=1 (rom cooking for the Galaxy S)..
ripped the zImage out of it, and dd'd it to my bml5 kernel.. Rebooted.. and everything worked.
Code:
Linux version 2.6.32.9 ([email protected]) (gcc version 4.4.1 (Sourcery G++ Lite 2009
q3-67) ) #1 Thu Dec 2 00:58:01 KST 2010
This kernel is a couple of MB bigger than the stock one, so I'm not sure what additional functionality it has (if any), but briefly playing around with it doesn't seem like there are any issues.
I'm running JPA currently, but going to try dropping the JPB kernel on it. Keep you guys posted..
...............
Hrm, nevermind.. Looks like after every reboot the kernel gets reverted. There's a tool for the Galaxy S called redbend_ua that's supposed to be used to flash bml live. Trying to get it working.
.............................................
Running JPA with the JPB kernel right now:
Code:
Linux version 2.6.32.9 ([email protected]) (gcc version 4.4.1 (Sourcery G++ Lite 2009
q3-67) ) #1 Sat Dec 4 19:45:05 KST 2010
Going see how it runs.. Battery life was my main issue before running JPB.
You could flash a zimage inside a PDA.tar with Odin as it is intended if redbend does not work on the g3... i really like the experimenting that is going on here at this time...
Btw, flashing kernel from sgs wont really work i think, since the sgs has armv7 CPU and the g3 has armv6 with very different instruction set and CPU frequency table. If you want to experiment with kernels you should download sztupys kernel building vm and the i5800 sources from Samsung and build your own one, when this is working you could try some optimizations like hardcore made them and so on.
FadeFx said:
You could flash a zimage inside a PDA.tar with Odin as it is intended if redbend does not work on the g3... i really like the experimenting that is going on here at this time...
Click to expand...
Click to collapse
I figured that would work. I just have a tar file with zImage in it by itself and choose it in the "One Package" and it seems to do the trick.
Flashing the Galaxy S kernel via this method made me stuck on the i5800 screen... So clearly that kernel won't work (assuming it's due to the differences in bml numbering, etc).. I also tried the Gingerbread release for the Nexus S (which supposedly works on the Galaxy S), and the same result unfortunately.
Gonna keep experimenting =)
I also wouldn't mind grabbing the FROYO sources when they're available (only 2.6.27/29 sources are available right now) and maybe adding in fastboot support.. That would be nice compared to requiring to use ODIN... But that also could be a bootloader thing - which in that case would not work.
Huh updated my previous post while you WWW writing this...
precurse said:
I figured that would work. I just have a tar file with zImage in it by itself and choose it in the "One Package" and it seems to do the trick.
Flashing the Galaxy S kernel via this method made me stuck on the i5800 screen... So clearly that kernel won't work (assuming it's due to the differences in bml numbering, etc).. I also tried the Gingerbread release for the Nexus S (which supposedly works on the Galaxy S), and the same result unfortunately.
Gonna keep experimenting =)
I also wouldn't mind grabbing the FROYO sources when they're available (only 2.6.27/29 sources are available right now) and maybe adding in fastboot support.. That would be nice compared to requiring to use ODIN... But that also could be a bootloader thing - which in that case would not work.
Click to expand...
Click to collapse
Fastboot in fact is a bootloader thing. But redbend would be cool, you'd have to look into the install script in that kernel update.zip, there must be a line to call the redbend.ua binary that is included in the zip also, maybe there the bml partition is specified where the zimage has to go to as a parameter...
FadeFx said:
Huh updated my previous post while you WWW writing this...
Click to expand...
Click to collapse
Nice.. Yeah, I already got the sources earlier. Supposedly there is still source code that's unobtainable which is required to get the phone working - so building the kernel alone isn't going to cut it.
I also read (though not how accurate it is) that you could avoid the proprietary rfs that samsung uses, and make this phone work with yffs(2) - which stock Android uses to run on anyways. So there are a lot of options, and getting rid of rfs would be I think - as I've read it's pretty ****ty.
FadeFx said:
Fastboot in fact is a bootloader thing. But redbend would be cool, you'd have to look into the install script in that kernel update.zip, there must be a line to call the redbend.ua binary that is included in the zip also, maybe there the bml partition is specified where the zimage has to go to as a parameter...
Click to expand...
Click to collapse
I tried specifying the bml partition properly and everything - it just errors out. I'll probably try messing around with it further - but it appears ODIN does what I need it to do for now. It would just be really nice to have the option of flashing from other operating systems than just Windows.
Someone was saying Samsung includes Fastboot (Forced upload by keypressing mode) which can be brought up with holding Home + Vol Up + Power. Though, trying it briefly showed no devices in fastboot after I plugged it into my PC. It's not a driver thing.
I don't think forced upload is in any way related to fastboot, since fb gives a console output normally. Redbend may be needed in a armv6 compatible version also. Gona find out...
FadeFx said:
I don't think forced upload is in any way related to fastboot, since fb gives a console output normally. Redbend may be needed in a armv6 compatible version also. Gona find out...
Click to expand...
Click to collapse
The more I read into this, the more I almost wished I went with something like the Nexus series' ... But then they're also like 3-4x the cost.
As long as the bootloader doesn't get flashed, I think it'd be pretty hard to brick this phone unless it gets overclocked and kills hardware =)
precurse said:
The more I read into this, the more I almost wished I went with something like the Nexus series' ... But then they're also like 3-4x the cost.
As long as the bootloader doesn't get flashed, I think it'd be pretty hard to brick this phone unless it gets overclocked and kills hardware =)
Click to expand...
Click to collapse
Oc can only freze but not brick a CPU, over volting is the dangerous thing...
For redbend you'd have to loock in /sbin if the binary is there... i have also read of some open source alternative that can do the same...
Info on redbend for sgs: http://forum.xda-developers.com/showthread.php?t=765724
The unobtainable sourcecode should be in the initramfs as binary, its mostly driver stuff.
Do we have an initramfs anywhere? I only thought there was a zImage..
Is this the open source alternative you're speaking about?
http://www.glassechidna.com.au/products/heimdall/
And there is a redbend_ua file there. However, it doesn't obey any type of command line arguments. That was the thread I was reading about redbend before actually. According to it: "redbend_ua working binary. (some firmware ship a new binary that does not accept command line parameters)"
Perhaps JPA doesn't accept them?
I'm just looking at the /fota.rc file... Like, there are lines commented out for yaffs2.
Code:
mount rfs /dev/block/stl6 /system check=no
# mount yaffs2 /dev/bml6 /data nosuid nodev
mount rfs /dev/block/stl7 /data nosuid nodev check=no
There HAS to be a way to convert from rfs to yaffs2 with the G3
precurse said:
Do we have an initramfs anywhere? I only thought there was a zImage..
Is this the open source alternative you're speaking about?
http://www.glassechidna.com.au/products/heimdall/
And there is a redbend_ua file there. However, it doesn't obey any type of command line arguments. That was the thread I was reading about redbend before actually. According to it: "redbend_ua working binary. (some firmware ship a new binary that does not accept command line parameters)"
Perhaps JPA doesn't accept them?
Click to expand...
Click to collapse
The initramfs is inside the zimage, i think it should be provided along with the sources also. If not, there is a howto for extracting the initramfs from a zimage in the i9000 section.
Heimdall is an alternative to Odin that is platform independent. However it'd have to be adapted to the g3. I already asked Benjamin Dobell to do it, but he wouldn't for some reason.
Maybe we should ask someone using older firmwares to extract a redbend.ua for testing
precurse said:
I'm just looking at the /fota.rc file... Like, there are lines commented out for yaffs2.
Code:
mount rfs /dev/block/stl6 /system check=no
# mount yaffs2 /dev/bml6 /data nosuid nodev
mount rfs /dev/block/stl7 /data nosuid nodev check=no
There HAS to be a way to convert from rfs to yaffs2 with the G3
Click to expand...
Click to collapse
I think yaffs2 wont be an option as it isn't for the i9000, since the devices are built using onenand that takes care of wearleveling by itself and wont accept a pure band filesystem since it emulates a block device to the system if i am not mistaken.
FadeFx said:
The initramfs is inside the zimage, i think it should be provided along with the sources also. If not, there is a howto for extracting the initramfs from a zimage in the i9000 section.
Heimdall is an alternative to Odin that is platform independent. However it'd have to be adapted to the g3. I already asked Benjamin Dobell to do it, but he wouldn't for some reason.
Maybe we should ask someone using older firmwares to extract a redbend.ua for testing
Click to expand...
Click to collapse
Good call.. I assumed that was it if there was actually one..
http://forum.xda-developers.com/wiki/index.php?title=Extract_initramfs_from_zImage
I believe the /sbin directory is in the initramfs, since there is no /sbin in the factory.rfs file (this file is ONLY /system). I'll see if I can extract it from an older firmware to see how it works. It does look like the samsung bootup scripts for OTA updates is in fact calling:
service redbend_ua /sbin/redbend_ua all
oneshot
FadeFx said:
I think yaffs2 wont be an option as it isn't for the i9000, since the devices are built using onenand that takes care of wearleveling by itself and wont accept a pure band filesystem since it emulates a block device to the system if i am not mistaken.
Click to expand...
Click to collapse
Yeah, I was thinking there is more to it. However, I'm thinking it's just a kernel thing... So if a kernel gets built that doesn't require that, and the filesystem matches that - I don't see how that wouldn't work.
I'm just brainstorming. There might really be a technical limitation though.
There in fact is a hardware limitation, since the onenand controller does this on hardware, its not a driver issue at all. That's why the sgs guys use ext filesystems for this... ext4 would be the way to go.
Btw, sorry that i can't help experimenting, but i never have written one line of code in c or c++ nor have i ever compiled a kernel by myself, i am just a Guy reading to much in forums, that's why i know all that for me useless **** and am just happy to share my knowledge to keep others from having to go a way that has already been gone...
All good. Maybe you will start =)
I got the initramfs extracted now.. I'm tempted to make some customizations to it (like the default.prop, etc). I'll grab the redbend from the older ECLAIR firmwares and see how it works.
Btw, you should rename the thread since this has nothing to do with i9000 anymore
conclusion first: it was possible.
i searched for custom mtd info for chacha on google, and i found some info in chinese suggested it was possible to apply custom mtd on chacha.
http://wenku.baidu.com/view/b029ab6027d3240c8447ef67.html
i don't speak chinese, but google translation helped. i used Mikevhl's recovery (http://forum.xda-developers.com/attachment.php?attachmentid=749943&d=1318622558), and also FR-Custom-MTD-v1.5.6-boot.zip (http://115.com/file/aqvgn30z#) and FR-Custom-MTD-v1.5.6-recovery.zip (http://115.com/file/aqvgnzmc#) as the chinese instruction said although i don't know where these files came from (maybe somewhere here?)
the procedure itself was the same as desire (bravo) or any other devices, and after the process, i got;
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 214004 32 213972 0% /dev
/dev/block/mtdblock4 5120 1624 3496 32% /cache
/dev/block/mtdblock3 153600 150292 3308 98% /system
/dev/block/mtdblock5 307200 2560 304640 1% /data
yay!!
unfortunately, adlx.xda's v5.0.2.8 didn't work with these patches... sorry, if this info is already around here.
p.s. as usual, this patch automatically mounts /cache to /sd-ext when /cache partition is smaller than 20mb. however, /cache/download won't be created automatically which means vending.apk (market) fails to start. when you set /cache less than 20mb, you'd need create sd-ext partition on your sd card and either add init.d script to create /cache/download ot do it manually.
Interesting, but sorry I don't read chinese :-(. I understand it's for changing the default partition layout on the Chacha.
Isn't it easier to use App2SD?
What are the patches? Do you why it doesn't work with my CWM build (maybe we can improve it so it work).
adlx.xda said:
Interesting, but sorry I don't read chinese :-(. I understand it's for changing the default partition layout on the Chacha.
Isn't it easier to use App2SD?
What are the patches? Do you why it doesn't work with my CWM build (maybe we can improve it so it work).
Click to expand...
Click to collapse
hi adlx.xda,
i don't read chinese, either;-)
it is sure easier for most people to use app2sd or data2sd, but i prefer to keep everything in the internal memory because it is possible if you change the partitions and don't install millions of apps. it is kinda a surprise to me that you didn't know about custom mtd...
anyway, the patches were originally created for htc desire, and adopted to other htc devices with low internal memory capacity like chacha/wildfire/etc.
http://forum.xda-developers.com/showthread.php?t=806321
there were two patches in the package; one for recovery partition and the other for boot partition. the recovery patch allows you to burn a custom rom according to the designated partition info. the boot patch allows you to change the boot image so that the device recognize the new partition info on boot.
when i use your recovery and the recovery patch together to burn a custom rom, chacha does not boot. i guess the patch does not modify something in your recovery correctly. on the other hand, this patch correctly modifies Mikevhl's old recovery. it is strange the patch can be used for the latest recovery for htc desire...
thx for your attention.
qt
could also be the repackaging of the kernel if it's patched. I tried for weeks unsuccessfully to unpackage and repackage a kernel for the status/chacha and had no luck. I was wanting to do some clocking tweaks.
bedwa said:
could also be the repackaging of the kernel if it's patched. I tried for weeks unsuccessfully to unpackage and repackage a kernel for the status/chacha and had no luck. I was wanting to do some clocking tweaks.
Click to expand...
Click to collapse
How do you try to unpack/repack? I wonder why it would fail.
I'll have to look at my setup on my netbook and get back to you. May be a few days. :-\ Kinda swamped ATM.
My Tab makes calls Yo! GT-P6800
i do read chinese, i saw this fews mths back but i dont have time for it... you will left with 24x~26xmb of free space.
I just wanted to update and say that I replied to this thread:
http://forum.xda-developers.com/showthread.php?p=35367602#post35367602
Basically, I'm wondering if the CustomMTD patches might be more compatible with a newer version of CWM compiled for our phone. I built a copy of 6.0.1.5, which mostly works, so if someone wants to give it a try, please do.
I managed to see custom partitions from CWM (not with the patches, but manually altering the recovery). 312MB /system and ~120MB /data (as an example just to try)
Apparently no problem with /system, but /data is not "working":
It appears as Read Only (it shouldn't actually event mount after moving/resizing it). Also not only it mounts, but it appears as 100%full, and won't allow me to do anything. I can't reformat it, remount rw,... I don't know why to be honest.
Now that I think about it, I should check dmesg.
dead links
it looks like all the links are dead.
here are the files you need.
qtotter said:
it looks like all the links are dead.
here are the files you need.
Click to expand...
Click to collapse
I managed to have it working, but I posted on another thread: http://forum.xda-developers.com/showpost.php?p=38029256&postcount=9
adlx.xda said:
I managed to have it working, but I posted on another thread: http://forum.xda-developers.com/showpost.php?p=38029256&postcount=9
Click to expand...
Click to collapse
so what files do we need, and what exactly do we do with them? I'd love to do the same as what you got working.
kronflux said:
so what files do we need, and what exactly do we do with them? I'd love to do the same as what you got working.
Click to expand...
Click to collapse
IIRC I used no files/patch,... It was more a matter of doing the partition table right. I took some notes and made an excel spreadsheet to help me with the conversions.
I'm on holiday starting today, I probably won't be able to review my notes and write anything related to this this month. Ping me again in Septembre so I review my notes and write a post about it .
kronflux said:
so what files do we need, and what exactly do we do with them? I'd love to do the same as what you got working.
Click to expand...
Click to collapse
it came from this thread originally http://forum.xda-developers.com/showpost.php?p=8578368&postcount=1, and it is very common among HTC Desire users.
it is quite easy to change partition sizes, and all the files you need are the three files that i uploaded.
recovery_chacha.img: Mike's old recovery that is compatible with this method. Don't use other recoveries!!
FR-Custom-MTD-v1.5.6-recovery.zip: This will patch recovery so that it can handle new partition sizes.
FR-Custom-MTD-v1.5.6-boot.zip: This will patch boot (kernel) in NAND so that the system can handle new partition sizes.
Procedure for ChaCha:
Make sure your phone is S-OFFed
**Make a backup in recovery first**
Place FR-Custom-MTD-v1.5.6-recovery.zip & FR-Custom-MTD-v1.5.6-boot.zip on SD card
Create mtdpartmap.txt on SD card with size of system & cache like "mtd 125 5". For example, I wanted to use ajeevlal's cm10.1 with Japanese IME and other system apps built in /system, I needed 330MB on /system and only 5MB on /cache (because I didn't need large /cache to use int2ext+.) So, my mtdpartmap.txt was "mtd 330 5". if you want to do this by shell command, it's gonna be like: echo "mtd 330 5" > /sdcard/mtdpartmap.txt
Flash Mike's old recovery above in fastboot like "fastboot flash recovery recovery_chacha.img"
Reboot into recovery
Wipe system, data, and cache
Flash FR-Custom-MTD-v1.5.6-recovery.zip, this patches recovery to use the new partition sizes
Reboot into recovery
Wipe system, data, and cache again just in case
Flash ROM, or restore from backup, and it will be flashed to NAND based on new partition sizes
Prior to rebooting, flash FR-Custom-MTD-v1.5.6-boot.zip, this patches boot (kernel) in NAND to load with the new partition sizes.
Reboot
unless you change mtdpartmap.txt on SD card, you don't need to repeat 1 - 8 every time. once you have decided your favorite partition sizes, you can start from 9. also, if your backup includes a patched boot image already, you can even skip 12 as well.
if you do this with any other newer recoveries, your phone simply does NOT boot. Mike's old recovery cannot backup sd-ext partition, but you can always do it manually like "dd if=/dev/block/mmcblk0p2 of=/sdcard/ext-bkup.img bs=4096" or something anyway.
kronflux's recovery
by the way, i tried your CWM 6.0.1.5 Built From Adlx http://forum.xda-developers.com/showthread.php?t=1989839, but it does not patch boot correctly. so the phone won't boot.
as i repeatedly keep saying, you need mike's old recovery to do this. i have tried so many recoveries, and this old one is the ONLY that is compatible with these patches.
qtotter said:
by the way, i tried your CWM 6.0.1.5 Built From Adlx http://forum.xda-developers.com/showthread.php?t=1989839, but it does not patch boot correctly. so the phone won't boot.
as i repeatedly keep saying, you need mike's old recovery to do this. i have tried so many recoveries, and this old one is the ONLY that is compatible with these patches.
Click to expand...
Click to collapse
it's also too large to fit in the recovery partition properly I believe. would be great if we could come up with a partitioning table that has enough space for it, as well as a little more space for app/rom storage.
so what are you saying, that we need this other recovery to actually do the partitioning? or that only that recovery will work on a custom partition table?
Adlx was just saying above, he doesn't think he used any custom files or patches. naturally we'll see in september what he has to say about it.
I did it with my recovery, not Mike's, and it worked, but again, I did it manually.
Sent from my Galaxy S4 running CarbonRom "Adlx Edition"
kronflux said:
so what are you saying, that we need this other recovery to actually do the partitioning? or that only that recovery will work on a custom partition table?
Click to expand...
Click to collapse
basically, this process patches recovery and boot to rewrite the partition table. Only Mike's old recovery can do both correctly.
talking about other recoveries, the reason why the phone doesn't boot is either recovery patch failure or boot patch failure. because i know Mike's one works and am not a recovery dev, i didn't even try to find which part is not working.
however, you can easily check it by switching the recovery between patching recovery and patching boot. i guess the former part is not working correctly because the latter part is rather straight forward and simple.
i just don't understand what you want, actually. changing the partition sizes or learning the mechanism of changing partition table??
qtotter said:
i just don't understand what you want, actually. changing the partition sizes or learning the mechanism of changing partition table??
Click to expand...
Click to collapse
Essentially, changing the sizes of partitions to accommodate a larger recovery image(so that my CWM6 could be flashed and work properly), as well as add more space to the system partition so that we don't have to worry about flashing lite versions of Gapps, or slimming down roms so that they fit.
kronflux said:
Essentially, changing the sizes of partitions to accommodate a larger recovery image(so that my CWM6 could be flashed and work properly), as well as add more space to the system partition so that we don't have to worry about flashing lite versions of Gapps, or slimming down roms so that they fit.
Click to expand...
Click to collapse
i have already explained how to do it above... now, my /system is 330 MB, and /cache is 5MB to cooperate with ajeevlal's cm10.1, full gapps, additional system apps and int2ext+. i am quite happy with my chacha setting not worrying about free space of /data, and battery lasts almost forever during sleep.
well, it is such a simple procedure, but i don't need to promote it to other people myself. i simply wanted to share the info that i learned over one year ago with people who want to make /system smaller for stock rom or make /system larger for cm10 and above.
The question has been asked several times. Recently a senior member asked a similar question and was told to read post two of a thread. That post did not answer the question but created more doubt. So Im going to steal some information from various posts to hopefully clarify this. Please if I get anything wrong let me know so I can correct it. But most of this will be stripped from various posts.
What is a partition?
A partition is an area of allocated space, a division of the whole overall area of space. In this case our partitions on the Epic 4G are /System, /Data, as well as /Cache. All with set permanent sizes.
What is a partition map?
A partition map is the configuration of our partitions, it's what in a vagueness sets our required sizes for the divisions of our nand also known as flash memory. A partition or partition map should not be confused with a file system. An example would be BML and MTD.
What is a file system?
A file system resides on the partition map and governs the data being read/wrote/moved/etc by the Operating System, in this case Android. Changing a file system is less complex than an overall change in partition mapping. They again, are not the same thing.
What is MTD?
MTD is an Open Source Partition map. It allows those who are using it control over how their partitions are sized and how much space is allocated here and how much space is taken away from there. Currently on MTD we have 689 megabytes of space allocated to our /data partition allowing more to be downloaded from the market as an example. MTD as a partition config has YAFFS2 as a file system residing on it governing how data is transferred and the speed of which it is done. EXT2 through 4 aren't possible on the MTD platform, just as YAFFS2 may not be possible on the BML proprietary platform.
What is BML?
BML like MTD is a partition map, however it is proprietary in nature, Close Source if you will. The size for /System /Data /Cache is set and permanent and makes opening up space more of a task for Developers. Stock the Epic 4G comes on BML, and is running RFS as it's file system, once rooted you can leave RFS for EXT4 (Journaled or Un-Journaled) as long as the kernel you use allows for EXT4. But in the end, changing a file system on BML does not lessen or enhance the control you have over your partitions.
What does it mean for me as an end user?
As an End User, MTD is an opening to a new life for the Galaxy S 4G. Things like ICS, more space in data or system, are more within our reach and grasp due to the nature of Open Source MTD is immersed in. We're closer to the Captivate, Fascinate, Vibrant, and Galaxy S international by being on MTD, we have that new freedom they've had for a long time. Not to say things like ICS aren't possible on BML but with this we're at a better standing point.
Click to expand...
Click to collapse
Basically, the internal storage on your phone is a flash device.
BML and FSR (aka XSR) acts as a software-based FTL (Flash Translation Layer).
This allows you to put filesystems like fat or ext4 on a flash device.
Hardware FTLs are everywhere. Look at your memory stick for instance. There is an FTL between the usb device controller and the nand flash chips that actually store the data. You can format your memory stick with ext4, btrfs, ntfs, whatever...
Samsung decided to go further down the rabbit hole with RFS, which is basically a modified version of FAT(32?) with ACLs and Journalling. IMO, silly.
BUT, fsr/rfs are proprietary modules and are built with a kernel that has a set of symbols exposed. If I disabled debugging (like I did) and something in one of those fsr/rfs modules depended on it, then the fsr/rfs modules wouldn't load (unless you trick it).
Moving to controlling the flash on the phone (in which the flash type on this phone isn't nand, but OneNAND-Flex) with MTD gets us away from the proprietary modules, but introduces a new problem. Can't use ext4 for /system, /data, and /cache anymore. Instead you have to use a flash filesystem, like yaffs2 (which is what the CM supported Samsung phones use). I would like to see a test on this phone with UBI/UBIFS though. I think that might have better performance then yaffs2 or jffs2 (but almost everything, including my grandma is faster then jffs2... seriously).
Click to expand...
Click to collapse
Mtd is the open source partition system used by aosp. Doing so allows more flexibility in porting roms and building from source. The proprietary stuff can be removed and get away from having to keep things like VVM for voicemail **.
This also moves us more towards vanilla android experience. Getting rid of proprietary file systems and and apps and various things to work properly.
Stolen from this thread and this post.
**note Antonx has found a way to remove the requirement for VVM. But is still working out if removing the code will break VVM for those people that use it.
I suggest we put BML to MTD and MTD to BML guides in the stickies. I know this info exists, but having it in the stickies will save many noob disasters and questions as this is getting more and more popular.
Sent from my SGH-T959V using xda premium
itzik2sh said:
I suggest we put BML to MTD and MTD to BML guides in the stickies. I know this info exists, but having it in the stickies will save many noob disasters and questions as this is getting more and more popular.
Sent from my SGH-T959V using xda premium
Click to expand...
Click to collapse
BML -> MTD will be a non-issue now since as of the latest commits I made to the CM7 update system (and whatever MTD roms base themselves off of that) we will be able to flash using only the rom.zip. You no longer need to fiddle with the efs backup/restore since the rom.zip will take care of it for you. The basic procedure will be
Reboot to RED cwm
Flash rom.zip
You will be rebooted to BLUE cwm
Flash rom.zip again
I just tested this myself from a completely stock KJ6 install and got onto a working CM7 install using a build I just made (with working IMEI/network/data) using those exact steps.
EDIT
Going back to BML will require a one-click for the time being until we can find a better solution, preferably one that involves CWM
One thing I didn't understand - why do we need a separated one click flash just for bootloaders? Can't it be done on the same time?
2nd, do we really need the bootloaders flash if we move from GB MTD to GB BML?
I assume I can odin just the kj1 kernel after the stock one click, just to get root. Do we have an odin version of AntonX's 1.1.0 kernel?
Sent from my SGH-T959V using xda premium
Well the bootloaders aren't a problem if the person is already on gingerbread. I had been messing with flashing bootloaders via CWM a while back but that just got my phone bricked. Until someone with unbrickablemod helps me test this or I get my own phone ubm'd, we'll have to do it this way.
No, you don't need to flash bootloaders all the time. The only times you need bootloaders are from GB -> Froyo or Froyo -> GB.
You should look into making your own custom one click, it's as easy as opening the .jar file in a program like 7-zip and extracting the files within, then you can recompress them. You can customize exactly what gets installed. I say you start with bhundven's kj6 one click and replace the kernel with your favorite custom one.
The files that get flashed from a one click are these:
one-click.jar/com/AdamOutler/HeimdallOneClick/resources/ROMPackage/HeimdallPackage.tar.gz
If you open that, you'll see all the files that get flashed, particularly zImage and zImage-1.
zImage gets flashed into the KERNEL partition
zImage-1 gets flashed into the RECOVERY partition
As it stands now, both zImage and zImage-1 should be identical since we don't have any recovery images and we have to use a kernel image instead.
I recently rooted my phone with Tweaked V2.2 (which I'm currently using with Transparent ICS, which looks and works amazing, by the way. Thanks for that!). It does occasionally start to lag over time and the battery starts dropping fast (which, realistically, is probably an app I have on there, I'll need to sort out which one it is later). I'm trying to look at ways to optimize the phone and I have read a decent amount about Voodoo lagfix helping with lag and battery life.
The question I had was, does Tweaked V2.2 w/PBJ come with Lagfix installed or is it something I need to add/activate? I apologize in advance if this is kind of a stupid question or if there's a fundamental understand I'm missing. I'm by no means a master with all this stuff and I'm still in the learning stage of all that I can do with a rooted device.
Thanks in advance!
jbrookley said:
I recently rooted my phone with Tweaked V2.2 (which I'm currently using with Transparent ICS, which looks and works amazing, by the way. Thanks for that!). It does occasionally start to lag over time and the battery starts dropping fast (which, realistically, is probably an app I have on there, I'll need to sort out which one it is later). I'm trying to look at ways to optimize the phone and I have read a decent amount about Voodoo lagfix helping with lag and battery life.
The question I had was, does Tweaked V2.2 w/PBJ come with Lagfix installed or is it something I need to add/activate? I apologize in advance if this is kind of a stupid question or if there's a fundamental understand I'm missing. I'm by no means a master with all this stuff and I'm still in the learning stage of all that I can do with a rooted device.
Thanks in advance!
Click to expand...
Click to collapse
I'm actually wondering the same thing. I just flashed to imoseyon's 4.0 kernel so i could convert to ext4 but im not to sure how? Does it do it automatically or is there anything i have to do? I plan to flash back to PBJ kernel after. (I'm really just trying to get wifi to work w Tweaked v2.2) but my phone is also very laggy as well.
As long as you don't have the file /sdcard/voodoo/disable_lagfix, it will automatically convert to ext4 on first boot. To be sure, install Voodoo Sound and check the options. There should be a lagfix section in the app if you are running a compatible kernel (imoseyon is the only one for GB).
If you flashed the version of Tweaked that is labeled as having ext4 conversion included, you shouldn't need this. You can always check your status by running terminal emulator, and typing 'su', followed by 'mount'. Scroll up in the list and find /system, /data, /cache, and /dbdata. They should be ext4 if you're converted. The rest will still be rfs.
shrike1978 said:
As long as you don't have the file /sdcard/voodoo/disable_lagfix, it will automatically convert to ext4 on first boot. To be sure, install Voodoo Sound and check the options. There should be a lagfix section in the app if you are running a compatible kernel (imoseyon is the only one for GB).
If you flashed the version of Tweaked that is labeled as having ext4 conversion included, you shouldn't need this. You can always check your status by running terminal emulator, and typing 'su', followed by 'mount'. Scroll up in the list and find /system, /data, /cache, and /dbdata. They should be ext4 if you're converted. The rest will still be rfs.
Click to expand...
Click to collapse
shrike is rarely wrong, however, I'm not so sure that installing the EXT4 version of Tweaked 2.2 will convert you from RFS to EXT4 (not saying that he is wrong, just don't know that is the case). the conversion takes places at the kernel level (I think). IMO's kernel makes the conversion (to/from EXT4/RFS), and I don't think dwith included that kernel is his ROM package (I could be wrong though).
if you want to convert from RFS to EXT4, try my guide posted here: http://forum.xda-developers.com/showthread.php?t=1763951
but first, make sure which version you have based upon shrike's recommendations.
jco23 said:
shrike is rarely wrong...
Click to expand...
Click to collapse
Yeah he's correct on this. The ext4 zip of the rom, from a /system perspective, is identical to the rom-only and with-kernel zips. The ext4 version does include a kernel (the same as what is in the with-kernel version), but it also includes the tools and script needed to format the usually-formatted partitions as ext4. The only difference between the ext4 and the with-kernel zips is the fact that the ext4 version has the formatting stuffs included.
Oops I made a dumb post.
Thanks for the help. Of course, after the matter, I found a detailed guide on google.If any other noob needs help just search "tonsit ext4" and it should be one of the first results from chargeforums, a post by jco on 10th July, 2012.
Is it actually possible to use fuse to mount my external SD card when it is formatted with ext4 when on a TW ROM on my VZW GS3?
From reading, it seems like it should be possible, but nothing I have tried has worked. Seems like CM/ASOP does it automatically but when trying to duplicate it on TW, I've hit a wall.
I've read that you need a custom kernel to do it, but not sure which kernels support it as I'm not sure what needs added in order to support this. Is it some module that needs compiled in or just support for inet.d? Since even stock supports ext4, I'm guessing inet.d is all that's needed, meaning the stock kernel with inet.d support added should work, but I'm willing to use other kernels. (Tried lean, Zeus, and a couple others I can't think of off the top of my head but had no luck.)
If someone can direct me to a howto or give instructions that work for the GS3 on TW, I'd appreciate it. The ones I've been able to find via search, I've not had any luck getting to work. If using fuse won't work, but directly mounting it does, that would work for me as well as my Windows machines are able to read ext file systems. Fuse would be more convenient for plugging into other PCs though. (Maybe I'll install the ext drivers on all the computers in the district as part of the summer updates...)
--
Tapatalked from my VZW Galaxy S III.
Bumping this in hopes that someone knows the answer and just didn't notice the post.
Stock kernel and Anthrax kernel are the only two I know that support ext4 on TW. Anthrax is invite only currently. So that leaves stock pretty much.
countryfolk07 said:
Stock kernel and Anthrax kernel are the only two I know that support ext4 on TW. Anthrax is invite only currently. So that leaves stock pretty much.
Click to expand...
Click to collapse
You wouldn't happen to know how to get it to recognize my ext4 SD card would you? I've yet to be able to get it to mount. I'll flash stock back on and give it another try.
--
Tapatalked from my VZW Galaxy S III.
countryfolk07 said:
Stock kernel and Anthrax kernel are the only two I know that support ext4 on TW. Anthrax is invite only currently. So that leaves stock pretty much.
Click to expand...
Click to collapse
You sure stock kernel supports ext4?