GEEWIZ MEDIA 3.4 SCH-I500 JZO54K JELLY BEAN 4.1.2 ROM/KERNEL
RETIRED -- GEEWIZ MEDIA 3.4 WAS THE FINAL RELEASE OF GEEWIZ MEDIA BASED ON ANDROID 4.1
OTHER AVAILABLE GEEWIZ MEDIA VERSIONS:
GeeWiz Media 4 - AOSP Jelly Bean 4.2: http://forum.xda-developers.com/showthread.php?t=2088139
GeeWiz Media 3.4 is a Wifi-only ROM for the Samsung Fascinate, based on AOSP Jelly Bean 4.1. The goal of GeeWiz Media is to allow the Samsung Fascinate device to continue to be used as a media player-like device after it has been disconnected from cellular service. There is no support for cellular voice/data communication present in this ROM. Like it's predecessor GeeWiz, GeeWiz Media doesn't aim to provide a lot of bells and whistles or incorporate all of the latest and greatest tweaks and enhancements developed by the community; the aim is to provide a basic, stable, functional device.
GeeWiz Media 3.4 uses a modified version of the GeeWiz 2.8 Gingerbread (Linux 2.6) kernel with a number of very specific tweaks/hacks in order to continue to support the proprietary Samsung RFS file system and other features I wanted to carry over. As a result, this ROM may not be used in conjunction with any other Kernel, and this Kernel cannot be used in conjunction with any other ROM. Please consider it a "matched set", and they will always be updated/distributed together.
Your device needs to be set up as stock or stock-like (e.g. GeeWiz 2.8) before installing this ROM/Kernel. If you are currently running with an MTD-based platform, the device must be reverted back to the original OEM volume format. Please refer to the forum/thread were you acquired your current ROM for guidance on how to revert the device as necessary.
Installing this ROM/Kernel or any other provided component(s) will void your device's warranty, and I cannot be held responsible for any damages of any kind (including data loss) that are incurred either directly or indirectly by these packages and components. What you do to your device is ultimately your problem!
FEATURES
Android Jelly Bean AOSP build JZO54K (android-4.1.2_r1)
Wifi-Only, no support for Voice/Mobile Data
Google Apps version JZO54K from the Galaxy Nexus
All devices (GPS, compass, orientation, camera, flash) are functional
Supports OEM DBDATA volume to keep performance reasonable
Supports both RFS and EXT4 formatting on all volumes
OEM USB modes (CD-ROM/Kies/MTP) replaced with standard Android Mass Storage
Advanced Battery Settings: Maximum Charge, Automatic Recharge Point
Advanced CPU Settings: Maximum/Minimum Clock Speed, Governor Selection
Backlight Notifications built into system, controlled by the OS
Supercurio Voodoo Sound 10
Fascinate Dock audio simulates a true USB audio device for seamless output path switching
Custom Dock options - Enable BLN, Stay Awake, Enable audio output, Maximize volume
Bluetooth Tethering support
CREDITS
While it would be impossible to remember/cite every possible reference that was used during development, I would like to specifically thank the following teams/individuals for making their work public so that others could learn from it and in more cases than not, shamelessly "borrow" it:
jt1134 - A primary source of knowledge for all things Samsung Fascinate
sgtkwol - Maintains a Linux 2.6 kernel for the Epic that provided a vast amount of reference material for the kernel updates
pawitp - Fixed my video driver changes to eliminate a 'microlag' issue (thank you!)
teamhacksung - Maintains a large repository for all Galaxy S devices, I can't count how many code compares I did against their material
Cyanogenmod - When all else fails, if you can figure out how they are doing it ... well, it's just gonna work right.
rxwookie - A long time friend of all things GeeWiz and always picks up my slack here on the forums. I think he probably knows more about GeeWiz than I do!
KNOWN ISSUES
USB Mass Storage / ADB may not work after device has been docked
After docking and removing the device from a Samsung Fascinate dock, USB Mass Storage and/or ADB may stop working. When this occurs, the only way to restore USB connectivity is to power off the device and power it back on. Rebooting is not sufficient and will not alleviate the problem.
FIRST-TIME INSTALLATION RECOMMENDATION
This ROM performs significantly better when the device uses the EXT4 file system. Unfortunately, using ODIN will always format the device with the RFS file system. As of GeeWiz Media 3.2, the "Full Wipe" ODIN package has been modified such that it will format the data volumes (DATA, DBDATA, CACHE) with the EXT4 file system. This is now the recommended installation method for first-time installation.
If the "Full Wipe" ODIN package is not used, please note that your data must be wiped manually if coming from another ROM to avoid problems, and I strongly recommend converting, at minimum, the data volumes of the device (DATA, DBDATA, CACHE) to the EXT4 file system.
UPGRADING FROM GEEWIZ MEDIA 3.2/3.3
GeeWiz Media 3.2.x/3.3.x Versions can be upgraded directly to GeeWiz Media 3.4 without a need to wipe the device data or revert the file system back to RFS. The EDIFY update-zip below is compatible with most, if not all, recoveries and will work regardless of if the device is formatted with RFS or EXT4.
Your Dalvik-cache will be automatically wiped, so the first reboot will take a long time
Due to problems with some Google services after a kernel change, the Google Services Framework package will have its data cleared during installation. You will be prompted to accept Google's location services again
DOWNLOADS
EDIFY Update-Zip (ClockworkMod / GeeWiz Recovery) Compatible Downloads
GeeWiz Media 3.4 ROM/Kernel (EDIFY Update-Zip)
http://www.mediafire.com/file/hqspl05qgbcfmkx/geewiz-media-3.4-syskernel-01122013.zip
MD5: 69f5fc67c0751bd8413f4f4c3319b12f
GeeWiz 2.8 Recovery (EDIFY Update-Zip)
http://www.mediafire.com/file/5fxee76vrxv28eq/geewiz-2.8-recovery-04162012.zip
MD5: 9869d3138279d99f1237a442f7573cad
ODIN Compatible Downloads
GeeWiz Media 3.4 ROM/Kernel/Modem/Recovery/Data Wipe Full Update (ODIN)
This will delete all user data from your device, replace your RECOVERY with GeeWiz Recovery as well as replace your modem with the EH03 revision. Your data volumes will be formatted with EXT4 on the first boot
http://www.mediafire.com/file/b8un78kf6gbp5jn/geewiz-media-3.4-fullwipe-01122013.tar.md5
MD5: 8fc027d5274aeb7b29035c9b67d68d78
GeeWiz Media 3.4 ROM/Kernel (ODIN)
http://www.mediafire.com/file/db2o2sytj65ur3v/geewiz-media-3.4-syskernel-01122013.tar.md5
MD5: b3e2bba3e6e06ee91766f2d0b6f75852
GeeWiz 2.8 Recovery (ODIN)
http://www.mediafire.com/file/h5gov2c1r8836tj/geewiz-2.8-recovery-04162012.tar.md5
MD5: b70d4063dffaa9cd89629f307d3beae5
SOURCE CODEThe entire baseline for GeeWiz Media is available on github: http://www.github.com/djp952.
Device repo: android-platform-device-samsung-atlas (branch android-4.1.2_r1)
Kernel repo: android-kernel-atlas (branch android-4.1.2_r1)
HOW TO BUILD THE GEEWIZ MEDIA 3 ROM AND KERNEL
A common request I've gotten is how to build the GeeWiz Media ROM and kernel from source. I think GeeWiz Media 3 is a little less intimidating as a first step for getting into AOSP builds since it doesn't stray too far from the Android baseline, and the kernel is based on Samsung's stock model for the device rather than the enhanced MTD model. Whatever the reason, I'm happy to try and describe how I build these components and generate the packages that I post for the community. Sometimes it's normal, sometimes it's a bit wonky, but as long as I don't miss anything important it should be a workable process for anyone that would like to get into building custom Android builds.
I think GeeWiz Media 3 would be a great learning tool, it works as-is but leaves enough room for additional customizations and enhancements that it may be a better place to start than jumping into something like Cyanogenmod or AOKP as your first project. It's up to date at the moment with the latest Android code as well, so that's a definite bonus as opposed to working with something like Gingerbread where tricks you learn may not apply to the next project you take on.
BUILD ENVIRONMENT
I use Ubuntu 12.04 Desktop x64 for my Android build environment, and even though Google states that this environment is "Experimental", I've not run into any issues with it. To get started, simply follow the directions Google has provided here:
http://source.android.com/source/initializing.html
If you are running on Windows x64, I can also recommend using a Virtual Machine as your build environment. I like Oracle VirtualBox the best, but the stock Fascinate code by Samsung has major USB problems with it, you won't be able to use ADB or Heimdall. For Fascinate-specific development I recommend VMWare Player since it can work with the stock USB. Note that you need an x64 OS and a CPU with Virtualization Support to host an x64 guest OS regardless of the software you choose. The best performance and compatibility will come from installing Linux natively on your system.
DOWNLOAD GEEWIZ SOURCE TREE
Once your environment is set up, you of course need some source code. I've opted to use Google's repo tool and AOSP manifests to control the source tree, so the first thing you need is the Google repo tool. Follow the first section of this document, entitled "Installing Repo":
http://source.android.com/source/downloading.html
I have two separate "builds", or in Android terms Manifests out there. One is called DEFAULT and includes just changes to AOSP necessary to support the Fascinate. The other is called CUSTOMBUILD and adds the light OS customizations I have done. Since I never use DEFAULT and I'm not sure t even builds at the moment, we're going to use CUSTOMBUILD, or as it's called here at XDA "GeeWiz".
Open a terminal window to your home directory (~/)
mkdir android
mkdir android/platform
cd android/platform
repo init -u https://github.com/djp952/android -m custombuild.xml -b android-4.1.2_r1
What we just did was initialize the repository for AOSP, but haven't downloaded anything yet. The -u argument to repo tells it where to find the manifest XML files. In this case, my github "android" repo. The -m tells it what manifest to use. The -b tells it what branch to pull. This is important because like most folks, I have multiple branches out there. I have been indicating at the very end of the first post what the current active branch is, android-4.1.2_r1 right now.
At this point, I suggest going into the ~/android/platform/.repo/manifests directory and having a look at the manifest file. (.repo is a hidden folder). Open up custombuild.xml in GEDIT and you can see that I've taken the AOSP manifest and simply replaced portions of it to point into my own github repos for things I've changed. I'll try to include details on how I manage this below so you could do something similar if you want to.
The most time-consuming part of building Android is downloading the code. Can't go much farther without it, so get yourself a cup of coffee and a good book ...
In the terminal, at the ~/android/platform directory
repo sync
The SYNC command uses the manifest to go get all the code. Most of it is going to come from Google, but all the bits I've altered will come from my github instead. It's going to take a very long time to download.
BUILD GEEWIZ MEDIA ROM
Once downloaded, we have to choose what device to build for. GeeWiz has two target devices, "atlas" and "atlas3g". Atlas is the Wifi-only target known here as "GeeWiz Media". Atlas3G adds to that changes required to include voice/data support (mostly courtesy of Cyanogenmod!). Let's assume if you're reading this, you're interested in the Wifi-only Atlas.
In the terminal, at the ~/android/platform directory
source build/envsetup.sh
lunch
The "Lunch Menu" (haha Google) will present you with a list of device builds to choose from. You can select by number, or you can type in anything not on the menu. As of this writing, the build we want is #9, full_atlas-userdebug. userdebug generates a generally release-quality build, but doesn't odex (pre-optimize) the APKs and has some additional debugging support you wouldn't ordinarily find. You could also type in full_atlas-eng for an "Engineering" build or full_atlas-user for a "Release" build. I think you'll prefer userdebug most of the time.
Select 9 - full_atlas-userdebug
make -j4 rompackage
This will kick off the build. It will take a long time the first time through. The rompackage argument is something I added to AOSP to support the Fascinate. This will build the EDIFY update-zip that I upload for everyone and use to generate the ODIN packages (more on that later). On typical Android devices, you would use otapackage (update-zip install) or updatepackage (fastboot install) instead. Fascinate is a special needs child, so it gets a special needs build process.
Once it's done, provided I didn't forget anything important here, you'll have a full ROM/Kernel package ready to be flashed via Clockworkmod or GeeWiz Recovery in the ~/android/platform/out/target/product/atlas folder. It will be named along the lines of full_atlas-rom-YYYYMMDD.HHMMSS.zip. Making a package for ODIN involves more steps, but I'll get to that. First I have to tell you how to build a modified Kernel ...
BUILDING THE GEEWIZ KERNEL
The Atlas and Atlas3G repos have a pre-compiled kernel in them that is packaged with the ROM build. This section will describe how to build and include customized versions of that kernel. First step is, of course, to get the source code. Both ROMs share a kernel but due to differences in the ramdisk (initramfs), they are built independently.
In a Terminal, at the ~/android directory
git clone https://github.com/djp952/android-kernel-atlas.git
cd android-kernel-atlas
git branch android-2.6 remotes/origin/android-2.6
git checkout android-2.6
Now the build environment needs to be set up. I use the compiler provided with AOSP to build the kernel as this is how Google does it. If you are using a different compiler, or have put your AOSP tree into a different location, you may have to modify these commands slightly.
In a Terminal, at the ~/android/android-kernel-atlas directory
export ARCH=arm
export SUBARCH=arm
export CROSS_COMPILE=arm-eabi-
export PATH=~/android/platform/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin:$PATH
NOTE: From this point forward, don't close that Terminal, otherwise you will have to execute the environment export commands again.
The kernel is built in three steps. This is necessary because the Fascinate doesn't conform to Android's models and we have to include the ramdisk (initramfs) in the kernel image. The first step is to select which device you are building the kernel for, which in this case will be "atlas_defconfig". (The other configuration for the GeeWiz 3G version is called "atlas3g_defconfig").
make atlas_defconfig
This initializes the kernel build for Atlas. Since we need to build the ramdisk as part of the kernel, the next step is to generate any loadable kernel module (.ko) files that need to be part of that ramdisk
make modules
The way I have the kernel set up, it will pull the necessary files for the ramdisk by looking at the device "initramfs.list" file, in the AOSP tree. The file that describes the atlas ramdisk, for example, is in ~/android/platform/device/samsung/atlas. If you examine this file you can see that it lists where all the files should come from, relative to the kernel source root directory. This explains why I went through how to build the AOSP tree before the kernel, the kernel depends on the AOSP build. Provided everything is in the right place, it's time to build the kernel
make
This executes the main kernel build. Should any ramdisk files be missing, it will error out early on and let you know what the problem is. Assuming everything goes well, your kernel will be in the ~/android/android-kernel-atlas/arch/arm/boot directory. It's named zImage and it's the combined kernel/ramdisk required for the Fascinate.
This zImage file can now be flashed directly to the device with Heimdall, packaged up for ODIN, etc. However in order to make it part of your AOSP build and corresponding EDIFY update-zip, we have to copy it into the AOSP tree and rebuild the ROM. It's a bit tedious, and other folks have different and more streamlined ways of accomplishing this, but this method has worked for me.
cp ~/android/android-kernel-atlas/arch/arm/boot/zImage ~/android/platform/device/samsung/atlas/kernel
cd ~/android/platform
source build/envsetup.sh
lunch full_atlas-userdebug
make installclean
make -j4 rompackage
This set of commands will clean out and rebuild your ROM package with the updated kernel.
CREATING ODIN PACKAGES
While not the most popular way for people to install your ROM, no guide would be complete without describing how to generate the ODIN-based installation packages. I like to provide a "Full Wipe" ODIN package that will take care of resetting the device while flashing the new ROM/Kernel, it's an easy way for people that are comfortable with ODIN to just completely replace the contents of their phone with your stuff. For this section, I'm going to assume that you are using GeeWiz Recovery, version 2.8 or later. Other recoveries will work, but as you may expect I'm most familiar with the one I made and I know for certain it has all the necessary features in place.
The ODIN factoryfs.rfs file must be generated by formatting the SYSTEM volume with RFS and then installing your ROM:
Copy your generated EDIFY update-zip to the SDCARD
Reboot into GeeWiz Recovery
Wipe the device data by selecting Wipe Device Data and then Wipe all User Data (Factory Reset)
Press the HOME key to return to the main menu
Format the SYSTEM volume with RFS by selecting Manage Volumes / Format Volumes / Format SYSTEM / Format SYSTEM [rfs]
Press the HOME key to return to the main menu
Select Install Update Package, and choose your EDIFY update-zip to install
After the installation is complete, reboot the phone by selecting Exit from the main menu. Not rebooting the device after the flash will result in a bad ODIN file more often than not. Trust me on this one.
After the device has fully booted, reboot it back into GeeWiz Recovery. The next step will be to generate a backup of the RFS-formatted SYSTEM volume to ultimately use with ODIN. GeeWiz Recovery can create these by choosing to execute a "raw dump" of the volume:
Select Manage Volumes / Backup Volumes / Backup SYSTEM / Backup SYSTEM [raw dump]
GeeWiz Recovery tries to keep volumes unmounted after it's done working, so the SDCARD must be mounted before the contents can be accessed with ADB:
Press the HOME key to return to the main menu
Select Manage Volumes / Mount Volumes / Mount SDCARD
GeeWiz Recovery will store the backup as /sdcard/backup/volume/SYSTEM-YYYYMMDD.img.gz, so as an example, I might pull it to my home folder with this command:
adb pull /sdcard/backup/volume/SYSTEM-20121022.img.gz ~/
The .gz file will contain a compressed copy of the backup, just open it up, extract the file, and then rename it to factoryfs.rfs. This is the SYSTEM volume for ODIN. There are also a number of other files you can include in your ODIN package to perform various other flash or wipe operations (I'll tell you where to get them, too)
boot.bin - Will replace the primary bootloader. VERY DANGEROUS to include, I strongly recommend against including it.
cache.rfs - Will wipe the CACHE volume; necessary if you want the device to boot into recovery automatically and run a command
dbdata.rfs - Will wipe the DBDATA volume
factoryfs.rfs - Will replace the SYSTEM volume
modem.bin - Will replace the CDMA modem
movinand.bin - Will wipe the DATA, PREINSTALL and FOTA volumes
param.lfs - Will replace the parameter block. Semi-dangerous to include, but required to ensure an initial boot into recovery mode
recovery.bin - Will replace the RECOVERY kernel and ramdisk
Sbl.bin - Will replace the secondary bootloader. VERY DANGEROUS to include, I strongly recommend against including it.
zImage - Will replace the BOOT kernel and ramdisk
To generate an ODIN-compatible tarball, gather the files you want to include and execute the following commands from a Terminal. Replace tarfilename.tar with the name you want to give the tarball, and replace file file file file with the names of the files from the table above you want to include:
tar --format=ustar -cf tarfilename.tar file file file file
md5sum -t tarfilename.tar >> tarfilename.tar
mv tarfilename.tar tarfilename.tar.md5
NOTE: If you rename the .TAR file, it will invalidate the MD5 checksum and you will have to md5sum it again.
OK, where to get the files. You can access a "full stock" ODIN package for the Fascinate, like the EH03 version that is available here on XDA to get copies of all the stock versions of these files. Or, you can use the ones from my ODIN "Full Wipe" package if you'd like as well. My ODIN tarball has a gimmick that you may find useful. If you include my copies of cache.rfs, param.lfs and recovery.bin, the device will initially reboot into recovery and automatically format the CACHE, DATA and DBDATA volumes with the EXT4 file system. It's a relatively simple trick, but an effective one to help improve the performance of your ROM. I also like to provide a "syskernel" tarball that includes only factoryfs.rfs and zImage. The benefit of this is that it will not wipe out any of your user's data. The downside is that the user may be responsible for going into Recovery on their own and executing any steps your EDIFY update-zip would have typically taken care of, like clearing the Dalvik-cache.
reserved 2
reserved 3
Good old me, always getting something wrong on a release Not usually fixed before any replies, but I didn't expect this ROM to be useful for than a precious few users anyway
Anyhow, it's rather important to apply the following patch, should anyone be trying this ROM out. This appears to resolve the problems with suspend/resume, including the ANR issue I mentioned above. I made customizations to the video subsystem to reduce CPU usage (by quite a bit), but didn't consider the ramifications of what happens when the screen is powered down properly. I've updated my method to be more like the original code behavior but still maintains the reduction in CPU load.
GeeWiz Media 3.0.1 PATCH (EDIFY Update-Zip)
- Resolves suspend/resume screen and device responsiveness issues caused by some poor coding on my part
http://www.mediafire.com/file/56287a1g1gr8iop/geewiz-media-3.0.1-patch-20120914.zip
MD5: 0ec6266f9c9acf3076c5638ccc8d52a9
Sorry for the oversight, folks.
I'm in a hotel room with no computer, and I want to flash this. Any way to do it just from a phone, and no Odin?
Sent from my SCH-I500 using Tapatalk 2
lolreconlol said:
I'm in a hotel room with no computer, and I want to flash this. Any way to do it just from a phone, and no Odin?
Sent from my SCH-I500 using Tapatalk 2
Click to expand...
Click to collapse
What ROM are you running now? If you're fully stock or running an MTD ROM like Cyanogenmod, I'm afraid that ODIN will be necessary. If you're running one of the community's older stock-based ROMs and have a recovery like Clockworkmod installed, shouldn't be a problem to download to the sd card, wipe data, and then install from recovery. You would just need to grab the big .zip file and the patch I just published.
Just to be sure, you saw that this ROM does not support cellular service, right? I'd hate for you to install it just to find out you have no phone!
To be honest, I would hold off until you are home and aren't going to run the risk of being without your device at all, but I'm flattered that you want to try it! Besides, my track record is always the same ... big release, big bug (check!), then a couple more bugs (hasn't happened yet, but they're there somewhere, I can feel it - LOL)
I have my old fascinate that I use as an mp3 so I'd be interested in continuing to test this for you. Maybe I'll find a way to get ISO working on the hardware so my wife can stop bugging me about hers.
Sent from my Galaxy Nexus using Tapatalk 2
I wanna test but my fassy is my dd
Fascinating PA2.12 Jelly Bean Sept 15 Devil 1.4.1...
Trying to flash with Odin...how long should it take to check the md5?
Edit: oop there we go
Sent from my Galaxy Nexus using Tapatalk 2
No luck. Boots straight into recovery.
Kaptinkrunk said:
I wanna test but my fassy is my dd
Fascinating PA2.12 Jelly Bean Sept 15 Devil 1.4.1...
Click to expand...
Click to collapse
I have started a full 3G version, but it will take some time and a lot of theft from Cyanogenmod to get it working. I can't promise that a full version will ever come to pass, but honestly I would prefer that than going back to update the old Gingerbread GeeWiz
kuronosan said:
No luck. Boots straight into recovery.
Click to expand...
Click to collapse
What ROM are you coming from?
Booting into Recovery once is expected when you use the "fullwipe" ODIN as it contains a sneaky automatic "wipe my data" command , but that should only happen once and then boot normally.
If you were running something that uses the "MTD" partitioning that the community has developed to try and make the Fascinate work more like a standard Android device, that has to be un-done first. I'm guessing this is the problem, but if you can give me more information as to what you were previously running, perhaps I can take a look and give you more appropriate advice? That's my best off-the-cuff guess ... if you have nonstandard partitions all kinds of weird stuff can happen if you flash something that's expecting the OEM layout
looks like am late to the parteh !!!
awesome as ever
Thankies and more thankies
djp952 said:
What ROM are you coming from?
Booting into Recovery once is expected when you use the "fullwipe" ODIN as it contains a sneaky automatic "wipe my data" command , but that should only happen once and then boot normally.
If you were running something that uses the "MTD" partitioning that the community has developed to try and make the Fascinate work more like a standard Android device, that has to be un-done first. I'm guessing this is the problem, but if you can give me more information as to what you were previously running, perhaps I can take a look and give you more appropriate advice? That's my best off-the-cuff guess ... if you have nonstandard partitions all kinds of weird stuff can happen if you flash something that's expecting the OEM layout
Click to expand...
Click to collapse
Yea, I thought just Odining the partition with your Rom from work would work but I had to go ahead and Odin eh03 first. Everything works great so far.
Sent from my Galaxy Nexus using Tapatalk 2
Does it matter which version of CWM is used?
Is ODIN'ing the 3.0 fullwipe the best way to come from CM10?
partaker said:
Does it matter which version of CWM is used?
Is ODIN'ing the 3.0 fullwipe the best way to come from CM10?
Click to expand...
Click to collapse
No matter what your current Rom is... I would recommend ODIN'ing the stock, bloated Verizon EH03 first, get it here...
http://forum.xda-developers.com/showthread.php?p=23171859
That will reset your recovery partition and file system back to stock. Note: This is REQUIRED if you are coming from CM10 our any other AOSP Rom. Otherwise, you'll get stuck in a Recovery bootloop or worse.
From there, you can ODIN the 3.0 full wipe GeeWiz Media edition... and finally you can then ODIN any recovery you want so you can easily flash up/out (ie. CWM or DJ's own GeeWiz Recovery).
Just to repeat the warning again... this Rom has no 3g connection and has no phone AT ALL. It is basically to turn your phone into a Galaxy S Player.
Hope this helps.
Sent from my SCH-I500 using xda app-developers app
Put it on my kids (my old one) runs great. jb runs slow on those old phones I think. Lag between opening apps. Other than that prefect for wifi only/ kid/game phone
Sent from my Galaxy Nexus using xda app-developers app
cuebask said:
Put it on my kids (my old one) runs great. jb runs slow on those old phones I think. Lag between opening apps. Other than that prefect for wifi only/ kid/game phone
Sent from my Galaxy Nexus using xda app-developers app
Click to expand...
Click to collapse
Yeah, I think we have to live with some lag here and there, especially with the way I chose to implement the OS (as close to how Samsung did it as I could). I've seen some data-heavy applications really slow down on me in daily use too. The Google version of the Browser seems especially annoying, I may ultimately opt to use the AOSP one, I've been very disappointed that they haven't fixed some issues that have been around since the first Jelly Bean builds. I also have trouble occasionally with my "Sonos Controller" application ... it just gets really slow on me, and takes the rest of the device with it. At least with the Browser I can say "hey -- my Galaxy Nexus does the same thing!" lol.
But hey -- thanks for the props! I'm really glad it's coming in handy for a couple other folks out here besides myself!!
GeeWiz Media has been updated to version 3.1 and removed from "Beta" status. Version 3.1 updates the core Android platform to version JRO03R (android-4.1.1_r6), and includes a small kernel change. The updated ROM/KERNEL can be applied to an existing GeeWiz Media 3.0/3.0.1 Beta installation without the need to wipe data. I would consider this to be an "optional" update, Jelly Bean R6 didn't appear to add much that this ROM benefits from at all, and the kernel update solves a problem that may or may not be something you've even noticed.
I need to add a changelog, but here's what's new in GeeWiz Media 3.1:
- No longer considered a Beta after a week of full daily testing
- Updated kernel with patch from pawitp that addresses a "microlag" issue in my video driver
- Updated core Android OS to version JRO03R (android-4.1.1_r6)
Check the first post for the links, and THANK YOU for trying out GeeWiz Media!
PS - There have actually been more than a hundred downloads of this ROM .. wow. It's about 8% of what GeeWiz 2.8 had in it's first week (and about 2% of what GeeWiz Froyo had in it's first week!), but this is a very niche/special implementation without much mass appeal and I wasn't expecting more than 20-30 people at most. I'm very glad that the ROM has some level of usefulness even without 3G support, and I hope to steal, er... borrow, er.. implement ... the necessary stuff to make a fully enabled 3G version soon. Not sure how that will go, and this Wifi-only setup is honestly my original intention as an endgame, but we'll see! Thanks everyone! :laugh:
Related
Edit: To try and get a little more participation and interest, the definitions as of 11/1/2011 are found below (copied with permission). Note that there are still some specifics (like Modems and Kernels) that are specific to the Galaxy S, which will be updated later.
There is an excellent post by jmtheiss in the Captivate forums; it is sticky'd in the General forum named "XDA and Android Terms and Acronyms". This is an excellent thread to reference any unfamiliar terms in the various posts here as well, since all of the general concepts are the same (although many specifics need some work.). It's a great dictionary for beginners since it eases some of the steep learning curve in deciphering the somewhat arcane terminology being used by the veterans who take for granted that the definitions they use are understood. I'll take a stab at updating this thread (assuming there is any interest) with GS II specific terminology if anyone has any suggestions, but the OP has been helpful and is still updating the post with new definitions.
I'd encourage any beginners to look through the post since it answers many questions. (I found it very valuable myself at any rate!) Note, I'll clean it up for readability later to include the links from the original post. In the meantime I'd encourage you to hit the above link to the original thread if you are seeking more information, and scroll down to see if there is a link.
Hopefully this will address a few questions, and help anyone new to the forum. I've assembled a list of terms and acronyms used on the forum below. Terms with links go to sources or threads with additional information. An item in all caps in a definition is one that I've defined elsewhere.
Use CTRL+F to find a specific term.
FORUM RELATED
SEARCH: The button just above the title of the forum or thread you are in. This should be your first resort when trying to find information. See button screenshot below.
GENERAL: This is the place for posting anything general. These include tips, ideas, comments, etc.
Q/A: This is the place for posting any questions. If you have a bug to report in a program or ROM (and have the minimum of 10 posts), post it in the appropriate thread in the ANDROID DEVELOPMENT subforum.
ACCESSORIES: This forum is for any items that attach to the physical hardware of the Android device.
ANDROID DEVELOPMENT: This is the place for posting Hacks/Mods/ROMs/Modems/Kernels. Generally reserved for developers, there is a 10-post minimum before a user can post here. This is the place to inform developers of bugs or software issues - ask questions in the Q&A subforum.
THEMES AND APPS: This is the place for posting themes as well as programs. Many applications can be interchangeable with Android Development, so use your best judgement.
FWIW: Short for "For what it's worth"
OP: Short for Original Poster, or the person who originally started the thread.
PM: Short for Private Message. Allows users of XDA to send and receive non-public messages. Accessed from USER CP.
THREAD: An individual issue page on the forum. This thing you're reading is a thread.
THREAD TOOLS: A button that allows users to subscribe and unsubscribe from THREADs. Subscriptions can be accessed from USER CP. See button screenshot below.
USER CP: Short for User Control Panel. This button near the top of the XDA page allows users to update their avatar, personal information, and signature. PMs and subscribed threads can also be checked in this location. See button screenshot below.
YMMV: Short for "Your mileage may vary".
ANDROID DEVICE RELATED
ADB: Short for Android Debug Bridge. Part of the Android Software Development Kit (SDK), it allows for ROOT-level access to the Android device from a computer.
AOSP: Short for Android Open Source Project. The open-sourced code from which individuals can build new distributions of Android.
APK: An Android executable file, similar to the .exe file in Windows. Most programs will install with a .apk file.
AUDIENCE CHIP: A voice processing chip installed on the I897/Captivate that provides noise suppression and voice quality enhancement for phone functions.
BACKLIGHT NOTIFICATION: A program that turns the LEDs behind the Menu/Home/Back/Search buttons on to indicate system events (e.g. new voicemail, etc).
BLN: Short for Backlight Notification. See BACKLIGHT NOTIFICATION.
BOOTLOADER: There are two of these that can be flashed, the primary and secondary bootloaders. These programs tell the Android device how to start up, and are critical to its functionality.
BRICK: An Android device that is completely non-responsive, i.e. nothing lights up, the screen does nothing, no combination of button presses cause any reaction. Can only be restored by JTAG, UNBRICKABLE MOD, or warranty service.
BUILD.PROP: A plain text file which contains environmental variables for the system to use during operation. Can be hacked to fake a different model for increased functionality, among many other operations.
BUSYBOX: An application that contains many standard Unix tools. Commonly used with TITANIUM BACKUP.
BUTTON COMBO: The act of pressing several buttons at the same time to produce a desired result (e.g. pushing volume up, volume down, and the power button for 10 seconds on FROYO will reboot into the RECOVERY menu). 3-Button Combo is a common example.
CLAY: An Android device that is not fully functional, but shows signs of functionality. Unlike a BRICK, the clay can be recovered without using JTAG. See also SOFT BRICK, BRICK.
CLOCKWORKMOD RECOVERY MENU: This is a program that allows you to install custom ROMS as well as do many other low-level customizations. Often referred to as the "RECOVERY MENU". See also "ROM MANAGER"
CM: Short for CyanogenMod. CyanogenMod is an Android build built from the Android Open Source Project, and its builds are usable on multiple different Android Devices.
CWM: Short for ClockWorkMod Recovery Menu. See CLOCKWORKMOD RECOVERY MENU.
DALVIK CACHE: The collection of program information stored for use by the DALVIK program. This can be cleared from the RECOVERY menu to resolve issues with the Android OS.
DALVIK: The Android operating system's memory management tool. This program handles which other programs are running and assigns memory to them
DEODEXED: Removing the .odex files from an APK file. The .odex files contain a list of dependencies for the associated file, and if something changes, the .odex (and similarly, the associated file) not longer function correctly.
DOWNLOAD: The download menu is the lowest-level interface to the Android device. Allows for full access to all flashable items on the device via the ODIN/HEIMDALL tool.
ECLAIR: The Android OS version 2.1.x. See also STOCK.
EFS: The directory /efs on the Android device's internal storage. Contains files with the Android device's IMEI, wireless devices MAC addresses, product code, and other information..
EXT4: A journaling file system (e.g. NTFS, FAT32 are file systems) often used by Linux distributions. Can be used with Android.
EXTERNAL SD: A micro SD card that has been inserted in the micro SD slot in the Android device. Can be removed.
FACTORY RESET: This will remove all user customizations in the Android OS, returning it to a factory state. Note: This will not wipe the Internal SD card.
FC: Short for FORCE CLOSE. See FORCE CLOSE.
FLASH COUNTER: New with the Galaxy S II, this is a counter accessed by pressing vol up + vol down and then inserting the USB cable to your computer. (This is done from a powered down phone and you do NOT hit the power button.) This shows the number of times custom firmware has been uploaded to the device. See here for the full discussion on what this means and how to avoid it. This can be used to show you have voided your warranty even if you have returned to full stock. There are methods around this (at least for now) by using a USB Jig, or writing the zImage directly to the device without using a bootloader.
FLASHING: The act of writing code to the Android device. ROMs, MODEMs, KERNELs, and BOOTLOADERs can all be flashed. Independent from, and having nothing to do with, Adobe's Flash product.
FORCE CLOSE: When a program on the Android device becomes unstable, the DALVIK program will force it to terminate to prevent further system instability.
FREEZE: Specific to TITANIUM BACKUP. Using the TITANIUM BACKUP tool, the user changes a program into a non-functional, but still installed, state. Useful for identifying problem and FCs.
FROYO: The Android OS version 2.2.x. This version of Android OS was released via AT&T to the captivate as an update over KIES MINI.
GB: Short for Gingerbread, the Android OS version 2.3.x.
GOVERNOR: A program that interacts with the device hardware to increase or decrease the processor's clock speed (e.g. at low usage, it will set the processor speed to 400 MHz, but as usage increases, it would scale up to 1000 MHz).
HEIMDALL: An open-source program by Benjamin Dobell that allows the Android device to be flashed back to stock or with custom software. See also ODIN.
HEIMDALL ONE-CLICK: An open-source, cross-platform, auto-dependency-installing, Linux, Windows and Mac one-click ROM deployment system based on the Open-Source project Heimdall, with multiple adminsitrative, technical and engineering controls making it much less likely to "brick" a phone then ODIN. Heimdall One-Click was created by Recognized Developer Adam Outler.
HSUPA/HSDPA: Short for High Speed (Up/Down) Packet Access. This is 3G+, and is the Android device's internet speed level between 3G and 4G.
I9000: The Samsung Galaxy international model. SImilar to the Captivate, Fascinate, Vibrant, and Mesmerize.
IMEI: Short for International Mobile Equipment Identity. A unique number to identify GSM, WCDMA, and iDEN phones. Used by GSM networks to identify valid devices.
INTERNAL SD: The internal storage memory of the Android device. Not a physical SD card that can be removed.
JIG: A piece of hardware that makes a physical connection between pins 4 and 5 of the USB slot to force the Android device into DOWNLOAD mode.
JTAG: A process of connecting directly to the main board of the Android device to rewrite corrupted BOOTLOADERS.
KERNEL: The collection of software drivers and more "nuts and bolts" programs that allow the basic functionality of the device.
KIES MINI: A Samsung-proprietary program that allows flashing of official updates to the Android OS.
LAGFIX: Changing the file system used by the Android OS (ususally to EXT4) to reduce the perceived lag in the operation of the Android device.
LAUNCHER: A program that launches programs in Android. Examples are Touchwiz (Samsung), Launcher Pro, ADW Launcher, and Go Launcher.
MODEM: The software that interfaces with the phone's radio hardware to connect to cell phone towers.
MODEM DANCE: A combination of key presses, MODEM flashes, and reboots required to force some Android devices to restrict the band use to the 850 MHz WCDMA band.
NANDROID BACKUP: A complete system image backup of the Android device except for the MODEM and KERNEL. Can be accessed from CWM.
NO-WIPE PACKAGE: A rom update package that leaves the user's market apps intact while still performing the updates to the system files. Restoring from backup is not necessary. See also WIPE PACKAGE.
NV_DATA.BIN: An encrypted file in the /EFS directory that contains the Android device's IMEI number and product code. See also EFS.
OC: Short for Overclocking. See OVERCLOCKING.
OCLF: One Click Lag Fix - a outdated method of using the EXT2 file system to reduce perceived lag in the Android OS. See also LAGFIX.
ODEX: A file that is associated with an APK file, containing a list of the dependencies for the program. See also DEODEXED.
ODIN: A Samsung proprietary program that allows the Android device to be flashed back to stock or with custom software. See also HEIMDALL.
ODIN ONE-CLICK: A version/package of the ODIN program that contains and will preload the necessary files to flash back to STOCK (usually ECLAIR).
ODIN THREE BUTTON: A version/package of the ODIN program that will FLASH the necessary files to restore the three-BUTTON COMBO used to get a FROYO ROM into the RECOVERY MENU. Only needs to be used if the user's Android device is missing the files necessary. ODIN ONE-CLICK must be flashed prior to using this package to avoid CLAY/BRICK status.
ONECLICK UNBRICK: A program developed by recognized developer Adam Outler that will release the locks on an Android device that are holding it in a CLAY state.
OVERCLOCKING: Setting the processor's clock speed to run faster than its default setting, i.e. 1200 MHz (1.2 GHz) vs 1000 MHz (1.0 GHz).
PIT FILE: Short for Partition Information Table file. One of the possible file types used while flashing with ODIN or HEIMDALL.
PRIMARY BOOTLOADER: Also known as First Stage Bootloader. The first bootloader run at boot time, this bootloader finds RAM for the Android device, and hands the boot sequence off to the SECONDARY BOOTLOADER. File name is "boot.bin". See also BOOTLOADER, SECONDARY BOOTLOADER.
RAT: Short for Radio Access Technology. This determines how the network decides the QoS (quality of service) on the connection between the Android device and the carrier's data towers.
RECOVERY: The menu that allows a user to do many low-level operations on the Android Device. This menu can either be the stock Samsung menu, or the CLOCKWORKMOD RECOVERY MENU (CWM). See also CWM.
REORIENTED: Changing the code of a KERNEL from one device (e.g. Samsung Galaxy S) so that it will function on another device (e.g. Samsung Captivate).
RFS: A Samsung-proprietary file system (e.g. NTFS, FAT32 are file systems) used on STOCK Android. Stands for Robust File System.
ROM: The collection of programs, themes, and settings that create the general look-and-feel of your Android device. This is what most users will initially be wanting to change.
ROM MANAGER: The Android OS front end program for the CLOCKWORKMOD RECOVERY MENU (or CWM). Allows use of many of the CWM features from inside the Android OS. See also CWM.
SECONDARY BOOTLOADER: Also known as Second Stage Bootloader. The second bootloader run at boot time, this bootloader handles the processes required to allow the Android device to boot the main kernel, such as file systems, memory, and MODEM. File name is sbl.bin. See also BOOTLOADER, PRIMARY BOOTLOADER.
ROOT: Changing the permission level of the Android system to its most powerful level, the root user, allowing full access to the file system.
SILVER SPEAKER: One of the most powerful and dangerous modifications to the Android device available. Can cause a variety of results, from improved signal to radioactive cats in boxes. Should not be used by the infirm or those with faulty gluons.
SOFT BRICK: This does not exist. A misnomer for a device that is not functioning correctly, but still shows some signs of operation. See CLAY.
STOCK: The Android software version that comes installed on new devices, prior to sale to the user. On the original Captivate, it was Eclair 2.1. Can also be used to refer to the Android software issued from Samsung or the carrier.
TETHER: Connecting the Android device to a computer via a wired or wireless connection to allow the transfer of data through the Android device's internet connection. Commonly used to provide internet access to a laptop or desktop computer when other methods are not desired or available.
THEME: A collection of images, backgrounds, colors, font types, and other visual items to change the Android device's look and feel. Separate from LAUNCHER, and is usually FLASHed in CWM.
TIBU: Short for Titanium Backup. See TITANIUM BACKUP.
TITANIUM BACKUP: A backup utility available in the Android Market that allows users to back up their applications, the saved data for the applications, and system settings.
UNBRICKABLE MOD: A hardware modification that removes a resistor and reconnects another resistor to the removed resistor's active pad, permanently allowing the Android device to reach a development board state. This allows reloading of bootloaders that have previously been corrupted or incorrectly installed, along with preventing the Android device from ever reaching a true "hard brick" state. Originally developed by Recognized Developer Adam Outler.
UNDERVOLTING: Setting the voltage levels drawn by the Android device to a lower level to reduce overall battery usage.
UV: Short for Undervolting. See UNDERVOLTING.
VOODOO LAGFIX: Converts /system, /cache, /dbdata and /data to Ext4 with optimized parameters for speed but also guaranteeing data integrity. Also configures the write behavior of Linux to prevent lag from happening, plus applies some memory management providing a better balance than stock settings.
VOODOO COLOR: A series of improvements to the visual elements of the Android OS. Enhances clarity, offers color adjustments, and other visual tweaks.
VOODOO SOUND: A series of improvements to the audio elements of the Android OS. Enhances audio clarity, allows for more powerful adjustment to overall sound levels, plus additional tweaks.
WCDMA: Short for Wideband Code Division Multiple Access. An air interface standard in 3G mobile communications networks that allows higher speeds and more users.
WIPE PACKAGE: A rom package that will format the portions of the Android device where the user's market apps are stored, in addition to any updates to the system folders. After a wipe package is installed, the user will have to restore apps from a backup or redownload them from the Android Market. See also NO-WIPE PACKAGE.
ZIPALIGNED: An archive alignment tool that provides important optimization to APK files. The purpose is to ensure that all uncompressed data starts with a particular alignment relative to the start of the file. Reduces RAM consumption.
ACRONYMS SPECIFIC TO MODEMS, KERNELS, AND ROMS
Note: The Modems and Kernels below are for the Galaxy S, not the Galaxy S II at this time. They will be updated later.
MODEMS
Note: most modems are referred to by the last three letters - e.g. JP3, JK3, JK4.
DTJP3: FROYO (I9000 KERNEL ONLY)
AOJP3: FROYO (I9000 KERNEL ONLY)
BVJP3: FROYO (I9000 KERNEL ONLY)
UGJK3: FROYO (I9000 KERNEL ONLY)
UGJK4: FROYO (I9000 KERNEL ONLY)
TLJL3: FROYO (I9000 KERNEL ONLY)
BVJJPD: FROYO (I9000 KERNEL ONLY)
XXJPY: FROYO (I9000 KERNEL ONLY)
UGJL2: FROYO (I9000 KERNEL ONLY)
BUJS1: FROYO (I9000 KERNEL ONLY)
ZNKP1: FROYO (I9000 KERNEL ONLY)
VJJPG: FROYO (I9000 KERNEL ONLY)
UBJP9: FROYO (I9000 KERNEL ONLY)
ZSJPG: FROYO (I9000 KERNEL ONLY)
TDVJP9: FROYO (I9000 KERNEL ONLY)
XXJVE: FROYO (I9000 KERNEL ONLY)
XXJQ1: FROYO (I9000 KERNEL ONLY)
UGKC1: FROYO (I9000 KERNEL ONLY)
XXJVK: GINGERBREAD (I9000 KERNEL ONLY)
BUJV3: GINGERBREAD (WCDMA 1900 KERNEL ONLY)
UBJV6: GINGERBREAD (I9000 KERNEL ONLY)
XXJVO: GINGERBREAD (I9000 KERNEL ONLY)
UGKG3: GINGERBREAD (I9000 KERNEL ONLY)
UCKB1: FROYO (CAPTIVATE KERNEL ONLY)
KERNELS
JVB: GINGERBREAD
JVH: GINGERBREAD
JVO: GINGERBREAD
JVP: GINGERBREAD
JVQ: GINGERBREAD
JVR: GINGERBREAD
KF1: GINGERBREAD
KH3: GINGERBREAD
KB1: FROYO
JPX: FROYO
JS8: FROYO
JF6: ECLAIR
ROMS
Note: These are only ROM names that use acronyms, not a complete ROM listing
CM: CyanogenMod. See "CM" in Android Device Related section.
MIUI: A Chinese built-from-source ROM. Short for "Mobile Internet User Interface". Also can refer to the MIUI music player, which has been included in other ROMs.
I'm still somewhat new to the board myself, so if I've incorrectly identified what something is or does, please let me know so I can update this post with the correct information. If you can think of any other terms or acronyms that should be included, let me know, and I'll put them up here. I've tried to give credit where it's due by direct linking, but if I've copied something and not cited properly, point it out and I'll update it.
Thanks for the tip bud.
Thanks really needed this I'm a quick learner but the terms allways help. Btw Miui is awesome!
Sent from my SGH-I777 using XDA App
Glad to help. Hopefully the thread won't get totally buried in the blizzard of posts here.
Sent from my SAMSUNG-SGH-I777 using Tapatalk
If anyone can point to a post that gives information on different Galaxy S II modems and kernel's, I'll start updating the post.
Add in AFAIK (as far as I know)
IIRC (if I remember correctly)
Add...
PEBKAC: Short for "Problem Exists Between Keyboard And Chair". Describing a problem as a PEBKAC error is an assertion that the problem in question is the fault of the user.
PEBCAK, AFAIK, ID-10-T error, etc - while they might be in common use, they aren't a term that increases peoples understanding of android devices. I'd like to keep it on track.
It's not meant to be a thread of every abbreviation on the internet -- that's way too much like real work.
Added definition for FLASH COUNTER.
Due to being a new user, I can't reply in the Development forum, so here goes:
I have a Galaxy Player 5.0 US, and wanted to try WT's ROM (http://forum.xda-developers.com/showthread.php?t=1623529). As noted in the thread, there is a (presumably now fixed) issue with its installation. I had that same mounting issue.
So I modified the install script by commenting out the lines that unmounted, formatted, and remounted /system and uncommented the "delete-recursive" line. This provided a successful installation after making sure that the proper filesystems were mounted in CWM.
The ROM then boots successfully with Entropy's kernel, and Wi-Fi, etc. work properly--I didn't notice any issues.
As a side note to the author: would it be possible to put the kernel as one of the options in the setup?
Mevordel said:
Due to being a new user, I can't reply in the Development forum, so here goes:
I have a Galaxy Player 5.0 US, and wanted to try WT's ROM (http://forum.xda-developers.com/showthread.php?t=1623529). As noted in the thread, there is a (presumably now fixed) issue with its installation. I had that same mounting issue.
So I modified the install script by commenting out the lines that unmounted, formatted, and remounted /system and uncommented the "delete-recursive" line. This provided a successful installation after making sure that the proper filesystems were mounted in CWM.
The ROM then boots successfully with Entropy's kernel, and Wi-Fi, etc. work properly--I didn't notice any issues.
As a side note to the author: would it be possible to put the kernel as one of the options in the setup?
Click to expand...
Click to collapse
Thanks for the feedback. I should be able to upload a new release in a day or so.
As for the kernel installation, I did consider the possibility of adding the option to install kernels but in the end I didn't put it in. My logic is that if you have a working CWM to flash this ROM, very likely you already have the correct kernel (because CWM is part of the kernel) and you rarely need to update the kernel.
If I put an option there for user to flash rj's kernel vs Entropy's kernel, I believe sooner or latter someone will flash the wrong kernel on the device which can be problematic.
If I can figure out some reliable ways to check the device type (US vs Intl), then it will be safe to include the kernel.
WT Ho said:
If I put an option there for user to flash rj's kernel vs Entropy's kernel, I believe sooner or latter someone will flash the wrong kernel on the device which can be problematic.
If I can figure out some reliable ways to check the device type (US vs Intl), then it will be safe to include the kernel.
Click to expand...
Click to collapse
That sounds reasonable - installing this rom won't modify your existing kernel at all, right?
A couple of final things:
1. In your next release, could you please update GO launcher? they made some pretty big improvements
2. me being the ocd neat freak that I am, I like it when there are very few folders in the root of /sdcard. Is there a way to put the "rom-settings" folder inside something like "Android"?
Thanks,
Mevordel
Well, it only took 2 years lol!
What is Kexec?
Kexec (kernel-execute) is a function of the Linux kernel that allows it to act as a bootloader to boot other kernels. Unfortunately, the standard implementation of kexec doesn't work quite right on most ARM devices due to poor driver support for hardware resets. The workaround is kexec-hardboot, a patch set that allows a kernel to be staged in RAM before performing an actual hardware reset through the phone's bootloader. Upon reboot the kexec-supporting kernel will check the magic location in RAM to see if a previously stored kernel is available, and if so, it will transfer execution to that kernel instead of booting itself.
Why use Kexec
It's a second-stage bootloader. The standard Android bootloader only allows two kernels to be installed at once - boot and recovery. This means that if you want a working recovery, you're only allowed one real OS kernel. If you want to dual-boot (or tri-boot or more) you're screwed. Kexec provides an answer to this. By replacing the boot kernel, kexec (with the kexecboot GUI) acts as a "second stage bootloader" allowing you to boot any number of kernels from any available storage devices. For instance, you have kexecboot in your boot partition and you can keep a kernel for Android installed in your Android system partition as well as an Ubuntu kernel and root filesystem on your SD card and be able to switch between Android and Ubuntu at boot time.
What is kexecboot
http://imgur.com/4GYomKX
Kexecboot is a graphical front-end for kexec. I have modified it to work with the kexec-hardboot patches. It scans all available storage devices for a boot.cfg file in which you define kernels, ramdisks, and kernel commandlines. You control it using volume up and down to move cursor, power to select.
Download
Get it here: https://mega.co.nz/#F!0ct3EaTD!wHWnGo1M_2smyKdzGMIYmw
The code
Kernel builder: https://github.com/CalcProgrammer1/kernel_quincyatt_kexec
This repository contains all the things you need to build a flashable kexecboot/kexec-hardboot enabled kernel image. It contains the ramdisk with the kexecboot binary and a script to package a flashable zip file. Included as submodules are the kernel source itself (kexec-hardboot branch, required to build the image) and the kexecboot source (optional, not used by default as you must build it using an ARM system, a pre-built binary is included if you don't want to build your own). The kernel source includes a defconfig called kexec_quincyatt_defconfig that sets the required config options for building a kexec-hardboot kernel.
Kexecboot Configuration File
Kexecboot replaces your boot kernel, so when you power up your phone it will go straight to the Kexecboot screen. The issue is now to provide kernels for kexecboot to boot into. This requires some work on your part, as you will have to store the kernel files (zImage and initrd) in a partition and write a configuration file to tell kexecboot where they are. This configuration file may contain multiple kernels, allowing you to have several different kernels available for the same OS or multiple OSes entirely. If you're coming from an Android system that distributes their kernel as a boot.img, you can use the abootimg program to extract it into a separate zImage and initrd.img binary.
The configuration file must be located on the path /boot/boot.cfg. This is relative to whatever partition/disk you are on, so for instance if you're setting up Android to boot from kexecboot, you would put your configuration file in /system/boot/boot.cfg (/data/boot/boot.cfg would work as well). You can also put a boot.cfg file on your SD card as long as you follow the /boot/boot.cfg path. Kexecboot automatically scans all available partitions for a boot.cfg file before it starts and builds a list of all available kernels across all detected boot.cfg files, so you may have Android in your /system partition and Debian on your SD card and both kernel lists will be shown together.
The Kexecboot web site provides a nice tutorial: http://kexecboot.org/documentation/how_to_write_config
The Note i717 bootloader passes a fairly long string of kernel arguments to the boot kernel. Since kexecboot overrides this for the kexec-booted kernel, you must provide this boot string in your boot.cfg file. Additionally, you may edit or add arguments to the command string here (such as setting console=tty0 instead of the default console=null so you can use the framebuffer console).
For example, here is my /system/boot/boot.cfg for CyanogenMod 11 (with kernel and initrd.img, extracted via abootimg, in /system/boot/)
Code:
# kexecboot configuration file
# CM11 default kernel
LABEL=CyanogenMod 11
KERNEL=/boot/zImage
INITRD=/boot/initrd.img
APPEND="androidboot.hardware=qcom usb_id_pin_rework=true no_console_suspend=true zcache [email protected] [email protected] sec_debug.reset_reason=0x1a2b3c00 pmem_sf_addr=0x7a000000 pmem_sf_size=0x6000000 console=null sec_debug.enable=0 sec_debug.enable_user=0 appsbark=0 msm_watchdog.enable=1 msm_watchdog.bark_time=30 msm_watchdog.bite_time=31 vmalloc=512m hw_rev=12 lpj=67702 androidboot.emmc=true androidboot.serialno=32c245ca androidboot.baseband=csfb"
I'm not sure how much of that you actually need, but you do need at least some of it because with an empty APPEND= it does not boot. You also do have to put the quotation marks around it or else parsing of one of the options will fail.
I'll admit limited understanding of what you're accomplishing here, but seems to me that this could lead to dual booting on the Note. Nice work.
Good luck.
Nice work! Thanks for the work you've done thus far. Unfortunately I have no way to help you out other than morale support! :highfive:
lactardjosh said:
I'll admit limited understanding of what you're accomplishing here, but seems to me that this could lead to dual booting on the Note. Nice work.
Good luck.
Click to expand...
Click to collapse
Pretty much what it comes down to, testing kernels and roms without having to flash into nand. I can't wait for dualbooting from Sd on the Note.
I have ORD , please help!!
My main goal here is native Linux, but if kexec works then you can boot custom Android dev kernels, native Linux kernels, other mobile OS'es, etc. The SGSIII team seems to have found some interesting kexec solutions for the Verizon SGSIII due to its locked bootloader. They've posted a good deal of kexec patches which I'm trying to bring to the Note, including a custom kexec-hardboot option that fully reboots the device into the new kernel (apparently to make sure the radio and such are working).
CalcProgrammer1 said:
My main goal here is native Linux, but if kexec works then you can boot custom Android dev kernels, native Linux kernels, other mobile OS'es, etc. The SGSIII team seems to have found some interesting kexec solutions for the Verizon SGSIII due to its locked bootloader. They've posted a good deal of kexec patches which I'm trying to bring to the Note, including a custom kexec-hardboot option that fully reboots the device into the new kernel (apparently to make sure the radio and such are working).
Click to expand...
Click to collapse
Wonderful, wonderful work!!! :thumbup::thumbup::thumbup:
Sent from my SAMSUNG-SGH-I717 using xda premium
Uh...It all sounded like this:
dual kernel (i'm gonna brick) kexec will allow (me to brick my phone).....with native linux applications ('im gonna brick my phone cause i'm stupid)....LOL
while i know what your doing, that in no way means i will ever understand it...LOL
But i will thank you in advance for what sounds like a sick mod for our notes...
Many thanks Dev !!!!
Kexec is actually (if done right) a good way *not* to brick your phone. To run kernels, you usually have to flash them to a restricted boot section of the memory, and if you flash all non-working kernels (to download, recovery, and main) then you have no way to use your phone, as it won't boot up. If you use kexec, your working kernel is safely stored on the boot partition and your development kernels can be wherever, and if it doesn't boot you can just hold down POWER to hard reboot into your good kernel.
The problem is that it doesn't seem to be working, I think I have the kexec support built properly but haven't been able to boot any kernels without it crashing.
CalcProgrammer1 said:
Kexec is actually (if done right) a good way *not* to brick your phone. To run kernels, you usually have to flash them to a restricted boot section of the memory, and if you flash all non-working kernels (to download, recovery, and main) then you have no way to use your phone, as it won't boot up. If you use kexec, your working kernel is safely stored on the boot partition and your development kernels can be wherever, and if it doesn't boot you can just hold down POWER to hard reboot into your good kernel.
The problem is that it doesn't seem to be working, I think I have the kexec support built properly but haven't been able to boot any kernels without it crashing.
Click to expand...
Click to collapse
I know you'll crack it ....
And when you do ....you'll be the galaxy note GOD !!!....LOL
your effort is much appreciated Sir ....even if I'm scared to use it , but will anyway ...lol
So I'm still confused as to why my kexec didn't work. I'm going to build a TouchPad kernel with it enabled and repeat the test on it, since I have a known-good kernel to boot against. I'll let you know how that goes.
Sent from my SAMSUNG-SGH-I717
Ok, so long-time-no-see but I'm reviving this post! Now that my Note 3 is happily running Cyanogenmod I have no urgent need for my Note 1 and can hack on it!
So far I haven't gotten kexec working, but I do have:
1. Kexecboot (graphical kexec frontend) is working, detects OS images appropriately
2. Framebuffer Console (text-mode display, USB OTG keyboard supported for interactive command line)
3. Overriding bootloader command line (to enable the fbconsole you need console=tty1 but the bootloader passes console=null)
4. Framebuffer console rotation (boot up in landscape or portrait, no way to switch without recompiling at the moment)
5. Most of kexec-hardboot ported from the HP TouchPad port, no clue if it's promising or not as so far it just crashes after a while of nothing
6. Ubuntu 13.04 (desktop edition) rootfs installed on SD card in a chroot, also taken from HP TouchPad
What I'm working on:
1. Kexec-hardboot port (needed to use kexec properly and boot kernels)
2. Fixing fbconsole glitching (framebuffer console displays garbled text that slowly clears up, no clue why...reading /dev/fb0 repeatedly clears up the display immediately and is a dirty hack that works well enough for testing)
3. Networking (either USB Ethernet or integrated WiFi, going to try backported brcmfmac driver)
4. Ubuntu (that's the long-term plan here)
5. Note 3 S800 port if I get everything figured out here
CalcProgrammer1 said:
Ok, so long-time-no-see but I'm reviving this post! Now that my Note 3 is happily running Cyanogenmod I have no urgent need for my Note 1 and can hack on it!
So far I haven't gotten kexec working, but I do have:
1. Kexecboot (graphical kexec frontend) is working, detects OS images appropriately
2. Framebuffer Console (text-mode display, USB OTG keyboard supported for interactive command line)
3. Overriding bootloader command line (to enable the fbconsole you need console=tty1 but the bootloader passes console=null)
4. Framebuffer console rotation (boot up in landscape or portrait, no way to switch without recompiling at the moment)
5. Most of kexec-hardboot ported from the HP TouchPad port, no clue if it's promising or not as so far it just crashes after a while of nothing
6. Ubuntu 13.04 (desktop edition) rootfs installed on SD card in a chroot, also taken from HP TouchPad
What I'm working on:
1. Kexec-hardboot port (needed to use kexec properly and boot kernels)
2. Fixing fbconsole glitching (framebuffer console displays garbled text that slowly clears up, no clue why...reading /dev/fb0 repeatedly clears up the display immediately and is a dirty hack that works well enough for testing)
3. Networking (either USB Ethernet or integrated WiFi, going to try backported brcmfmac driver)
4. Ubuntu (that's the long-term plan here)
5. Note 3 S800 port if I get everything figured out here
Click to expand...
Click to collapse
Long time in the making. Glad to see you're still at it. Hope you are able to get it working. Would be pretty cool. Good luck
If you can get this working up to kernel with freedreno I'd be all over working on getting Plasma Active onto this thing. I've missed having a real linux phone since my n900 died.
Got Bluetooth working from the command line!
Code:
# rfkill unblock all
# hciattach /dev/ttyHS0 any
# hcitool scan
It detected my Note 3 which I had set to visible! Hopefully I can pair a BT keyboard with this and lose the USB OTG dependency. Still working on figuring out WiFi, I have the brcmfmac driver from 3.13 backports compiled and loaded but the WiFi chip isn't being detected so the driver never creates an interface for it. The chip is a Broadcom BCM4330 WiFi/Bluetooth chip, and although both WiFi and Bluetooth share the same chip they use different interfaces to the SoC (UART for BT and SDIO for WiFi).
I plan on doing more research into getting the hardware working before I do any more work on kexec. It will be much easier to debug kexec I think knowing how to use WiFi/BT/USB/etc. The only hardware I'm not going to attempt at all is the modem as I don't use this device as a phone anymore and don't have a SIM card in it. That said, all the rmnetX entries that I think are modem interfaces show in ifconfig -a so maybe it is working.
My kernel source is here:
https://github.com/CalcProgrammer1/ubuntu-kernel-quincyatt
The kexec branch will have the kexec hardboot patches once I figure them out. I've also got a folder set up with a script to automatically build the kernel zImage, build the modules, build the backport driver modules, build the ramdisk from a ramdisk root folder, build the boot.img, and then package that up in a flashable .zip. I'll upload parts of this system as I complete them. I also have an Ubuntu rootfs on my external ext4 (or was it 3?) SD card that I ripped straight off my TouchPad. For now I'm just using a busybox shell in my ramdisk, dropping out of kexecboot into ash, setting up a chroot for the SD card, and chrooting into the Ubuntu rootfs that way. It's not ideal since Ubuntu's init process doesn't run but it does allow me to run all the installed utilites from said rootfs.
Edit: Rii Mini Bluetooth Keyboard paired and working! It was a roundabout way of doing so because dbus and upstart don't work in chroot so I had to use an old package called bluez-compat which provides the hidd command. I sideloaded the .deb with a flash drive. The command to pair a keyboard:
Code:
# hcitool scan
Scanning ...
XX:XX:XX:XX:XX:XX Bluetooth device name
# hidd --connect XX:XX:XX:XX:XX:XX &
XX:XX:XX:XX:XX:XX will be a hex value that is your keyboard's address. You find the address with the scan command and enter it on the hidd command to connect. I didn't have to enter any kind of passcode or pairing key, after running hidd it just started working.
http://imgur.com/2sV3TJr
I got it! I finally managed to get kexec hardboot working! I had to rewrite a bit of code in the kexecboot program to support kexec-hardboot better but I now have a bootloader that is working correctly, if slowly. I'll be posting my kernel source soon (it's a branch off of CyanogenMod's msm8660-common kernel) as well as my modifications to kexecboot itself. The kexec-tools binary I took out of the HP TouchPad port unmodified so I don't have the source for that (though it shouldn't be hard to find). I'll be looking into a Note 3 port soon, basically used the Note 1 as the guinea pig for this experiment.
If, somehow, you could adapt this for the ATT Mega 6.3 so as to bypass the locked tight bootloater.....you would be considered a hero!! People would build statues of you....write songs and name their children after you!!!!!?
Sent from my SM-T310 using XDA Premium 4 mobile app
Unfortunately you require an unlocked bootloader to install the kexecboot kernel. This isn't going to be a magic bullet for locked bootloaders. People have tried. For devices with exploitable bootloaders, it may help as you won't have to fake-sign kexec-booted kernels though.
CalcProgrammer1 said:
Unfortunately you require an unlocked bootloader to install the kexecboot kernel. This isn't going to be a magic bullet for locked bootloaders. People have tried. For devices with exploitable bootloaders, it may help as you won't have to fake-sign kexec-booted kernels though.
Click to expand...
Click to collapse
Grasping at straws, My Friend. Hoping that maybe this could be something like SafeStrap and could be d/l and installed as an APK.
Sent from my SAMSUNG-SGH-I527 using XDA Premium 4 mobile app
Got Debian booting! I also figured out how to get WiFi working from a non-Android Linux OS so this is definitely on track towards a full desktop OS!
To-do:
* X server, preferably with Freedreno GPU driver eventually
* Audio (q6.* firmware files and possibly an ALSA config)
* Startup scripts for Bluetooth initialization
* Figure out how to rotate the screen
dparrothead1 said:
If, somehow, you could adapt this for the ATT Mega 6.3 so as to bypass the locked tight bootloater.....you would be considered a hero!! People would build statues of you....write songs and name their children after you!!!!!?
Sent from my SM-T310 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I wont be having anymore children to name, but I can do a dog. He is too stoopid to know the difference. I can say aluminum foil and he will come running.
Sent from my SAMSUNG-SGH-I527 using XDA Free mobile app
GEEWIZ 3.4 SCH-I500 JZO54K JELLY BEAN 4.1.2 ROM/KERNEL
RETIRED -- GEEWIZ 3.4 WAS THE FINAL RELEASE OF GEEWIZ BASED ON ANDROID 4.1
OTHER AVAILABLE GEEWIZ VERSIONS:
GeeWiz 4 - AOSP Jelly Bean 4.2: http://forum.xda-developers.com/showthread.php?t=2088224
GeeWiz 3.4 is a ROM for the Samsung Fascinate, based on AOSP Jelly Bean 4.1. Like it's predecessors of the same name, GeeWiz doesn't aim to provide a lot of bells and whistles or incorporate all of the latest and greatest tweaks and enhancements developed by the community; the aim is to provide a basic, stable, functional device.
GeeWiz 3.4 uses a modified version of the GeeWiz 2.8 Gingerbread (Linux 2.6) kernel with a number of very specific tweaks/hacks in order to continue to support the proprietary Samsung RFS file system and other features I wanted to carry over. As a result, this ROM may not be used in conjunction with any other Kernel, and this Kernel cannot be used in conjunction with any other ROM. Please consider it a "matched set", and they will always be updated/distributed together. XDA community developed enhancements to the ROM or Kernel are encouraged, and will be given prominent feature status in this post.
Your device needs to be set up as stock or stock-like (e.g. GeeWiz 2.8) before installing this ROM/Kernel. If you are currently running with an MTD-based platform, the device must be reverted back to the original OEM volume format. Please refer to the forum/thread were you acquired your current ROM for guidance on how to revert the device as necessary.
Installing this ROM/Kernel or any other provided component(s) will void your device's warranty, and I cannot be held responsible for any damages of any kind (including data loss) that are incurred either directly or indirectly by these packages and components. What you do to your device is ultimately your problem!
FEATURES
Android Jelly Bean AOSP build JZO54K (android-4.1.2_r1)
Google Apps version JZO54K from the Galaxy Nexus
All devices (GPS, compass, orientation, camera, flash) are functional
Wifi (WPA/WPA2) and Bluetooth Tethering support
Supports OEM DBDATA volume to keep performance reasonable
Supports both RFS and EXT4 formatting on all volumes
OEM USB modes (CD-ROM/Kies/MTP) replaced with standard Android Mass Storage
Advanced Battery Settings: Maximum Charge, Automatic Recharge Point
Advanced CPU Settings: Maximum/Minimum Clock Speed, Governor Selection
Advanced In-Call Volume Boost Selection
Backlight Notifications built into system, controlled by the OS
Supercurio Voodoo Sound 10
Fascinate Dock audio simulates a true USB audio device for seamless output path switching
Custom Dock options - Enable BLN, Stay Awake, Enable audio output
CREDITS
While it would be impossible to remember/cite every possible reference that was used during development, I would like to specifically thank the following teams/individuals for making their work public so that others could learn from it and in more cases than not, shamelessly "borrow" it:
jt1134 - A primary source of knowledge for all things Samsung Fascinate
sgtkwol - Maintains a Linux 2.6 kernel for the Epic that provided a vast amount of reference material for the kernel updates
pawitp - Fixed my video driver changes to eliminate a 'microlag' issue (thank you!)
Entropy512- Customizations to allow WPA/WPA2 Wifi Tethering to work on the Galaxy S
teamhacksung - Maintains a large repository for all Galaxy S devices, I can't count how many code compares I did against their material
Cyanogenmod - The fact that this ROM can make a call at all is thanks to this team. So much of this effort is based on theirs!
rxwookie - A long-time supporter of all things GeeWiz and always takes the time to help other folks out here. I think he probably knows more about GeeWiz than I do!
ACTIVATION AND PROVISIONING
While I have no reason to believe that activation/provisioning wouldn't work properly on this ROM, it is a difficult thing to test on CDMA networks. Until it's been established that activation/provisioning is indeed working properly, I suggest you do not use anything like the ODIN "EFS Clear" option that may affect it. If the phone was properly provisioned before installing this ROM, it should maintain that provisioning. I have successfully activated a Fascinate on this ROM, but have not tested the process enough to be fully confident with it.
KNOWN ISSUES
USB Mass Storage / ADB may not work after device has been docked
After docking and removing the device from a Samsung Fascinate dock, USB Mass Storage and/or ADB may stop working. When this occurs, the only way to restore USB connectivity is to power off the device and power it back on. Rebooting is not sufficient and will not alleviate the problem.
FIRST-TIME INSTALLATION RECOMMENDATION
This ROM performs significantly better when the device uses the EXT4 file system. Unfortunately, using ODIN will always format the device with the RFS file system. Unlike previous versions of GeeWiz, the new "Full Wipe" ODIN package has been modified such that it will format the data volumes (DATA, DBDATA, CACHE) with the EXT4 file system on the first boot. This is now the recommended installation method for first-time installation.
If the "Full Wipe" ODIN package is not used, please note that your data must be wiped manually if coming from another ROM to avoid problems, and I strongly recommend converting, at minimum, the data volumes of the device (DATA, DBDATA, CACHE) to the EXT4 file system.
UPGRADING FROM GEEWIZ 3.2/3.3
GeeWiz 3.2.x/3.3.x Versions can be upgraded directly to GeeWiz 3.4 without a need to wipe the device data or revert the file system back to RFS. The EDIFY update-zip below is compatible with most, if not all, recoveries and will work regardless of if the device is formatted with RFS or EXT4.
Your Dalvik-cache will be automatically wiped, so the first reboot will take a long time
Due to problems with some Google services after a kernel change, the Google Services Framework package will have its data cleared during installation. You will be prompted to accept Google's location services again
DOWNLOADS
EDIFY Update-Zip (ClockworkMod / GeeWiz Recovery) Compatible Downloads
GeeWiz 3.4 ROM/Kernel (EDIFY Update-Zip)
http://www.mediafire.com/file/ascgikdaqdg3ai5/geewiz-3.4-syskernel-01122013.zip
MD5: 6b2e280f9d51492febec43b8b9fa3bd4
GeeWiz 2.8 Recovery (EDIFY Update-Zip)
http://www.mediafire.com/file/5fxee76vrxv28eq/geewiz-2.8-recovery-04162012.zip
MD5: 9869d3138279d99f1237a442f7573cad
ODIN Compatible Downloads
GeeWiz 3.4 ROM/Kernel/Modem/Recovery/Data Wipe Full Update (ODIN)
This will delete all user data from your device, replace your RECOVERY with GeeWiz Recovery as well as replace your modem with the EH03 revision. Your data volumes will be formatted with EXT4 on the first boot
http://www.mediafire.com/file/2266vgo7uma5xmk/geewiz-3.4-fullwipe-01122013.tar.md5
MD5: 0d6c2cf955d0024c925c2d10ce046e1d
GeeWiz 3.4 ROM/Kernel (ODIN)
http://www.mediafire.com/file/jzfwybqu6ns70ay/geewiz-3.4-syskernel-01122013.tar.md5
MD5: 46e17141a8f8a8ae48001c3e4653e088
GeeWiz 2.8 Recovery (ODIN)
http://www.mediafire.com/file/h5gov2c1r8836tj/geewiz-2.8-recovery-04162012.tar.md5
MD5: b70d4063dffaa9cd89629f307d3beae5
SOURCE CODEThe entire baseline for GeeWiz is available on github: https://www.github.com/djp952.
Device repo: android-platform-device-samsung-atlas3g (branch android-4.1.2_r1)
Kernel repo: android-kernel-atlas (branch android-4.1.2_r1)
Please see post #2 of this thread for an overview of how to build the GeeWiz ROM/Kernel from source as well as how to package your modifications. I would be happy to include any XDA community developed modifications or enhancements to the baseline as featured packages, add-ons or patches for GeeWiz!
Disclaimer: djp952 reserves the right to mercilessly kang your changes and assimilate them when you fix things that he was unable to. djp952 will also give you *major* props and full credit for the fix, so it's not that bad, right?
HOW TO BUILD THE GEEWIZ 3 ROM AND KERNEL
A common request I've gotten is how to build either the GeeWiz ROM or kernel from source. I think GeeWiz 3 is a little less intimidating as a first step for getting into AOSP builds since it doesn't stray too far from the Android baseline, and the kernel is based on Samsung's stock model for the device rather than the enhanced MTD model. Whatever the reason, I'm happy to try and describe how I build these components and generate the packages that I post for the community. Sometimes it's normal, sometimes it's a bit wonky, but as long as I don't miss anything important it should be a workable process for anyone that would like to get into building custom Android builds.
I think GeeWiz 3 would be a great learning tool, it works as-is but leaves enough room for additional customizations and enhancements that it may be a better place to start than jumping into something like Cyanogenmod or AOKP as your first project. It's up to date at the moment with the latest Android code as well, so that's a definite bonus as opposed to working with something like Gingerbread where tricks you learn may not apply to the next project you take on.
BUILD ENVIRONMENT
I use Ubuntu 12.04 Desktop x64 for my Android build environment, and even though Google states that this environment is "Experimental", I've not run into any issues with it. To get started, simply follow the directions Google has provided here:
http://source.android.com/source/initializing.html
If you are running on Windows x64, I can also recommend using a Virtual Machine as your build environment. I like Oracle VirtualBox the best, but the stock Fascinate code by Samsung has major USB problems with it, you won't be able to use ADB or Heimdall. For Fascinate-specific development I recommend VMWare Player since it can work with the stock USB. Note that you need an x64 OS and a CPU with Virtualization Support to host an x64 guest OS regardless of the software you choose. The best performance and compatibility will come from installing Linux natively on your system.
DOWNLOAD GEEWIZ SOURCE TREE
Once your environment is set up, you of course need some source code. I've opted to use Google's repo tool and AOSP manifests to control the source tree, so the first thing you need is the Google repo tool. Follow the first section of this document, entitled "Installing Repo":
http://source.android.com/source/downloading.html
I have two separate "builds", or in Android terms Manifests out there. One is called DEFAULT and includes just changes to AOSP necessary to support the Fascinate. The other is called CUSTOMBUILD and adds the light OS customizations I have done. Since I never use DEFAULT and I'm not sure t even builds at the moment, we're going to use CUSTOMBUILD, or as it's called here at XDA "GeeWiz".
Open a terminal window to your home directory (~/)
mkdir android
mkdir android/platform
cd android/platform
repo init -u https://github.com/djp952/android -m custombuild.xml -b android-4.1.2_r1
What we just did was initialize the repository for AOSP, but haven't downloaded anything yet. The -u argument to repo tells it where to find the manifest XML files. In this case, my github "android" repo. The -m tells it what manifest to use. The -b tells it what branch to pull. This is important because like most folks, I have multiple branches out there. I have been indicating at the very end of the first post what the current active branch is, android-4.1.2_r1 right now.
At this point, I suggest going into the ~/android/platform/.repo/manifests directory and having a look at the manifest file. (.repo is a hidden folder). Open up custombuild.xml in GEDIT and you can see that I've taken the AOSP manifest and simply replaced portions of it to point into my own github repos for things I've changed. I'll try to include details on how I manage this below so you could do something similar if you want to.
The most time-consuming part of building Android is downloading the code. Can't go much farther without it, so get yourself a cup of coffee and a good book ...
In the terminal, at the ~/android/platform directory
repo sync
The SYNC command uses the manifest to go get all the code. Most of it is going to come from Google, but all the bits I've altered will come from my github instead. It's going to take a very long time to download.
BUILD GEEWIZ ROM
Once downloaded, we have to choose what device to build for. GeeWiz has two target devices, "atlas" and "atlas3g" (Technically, there are three as I use the same build for "toro" - VZW Galaxy Nexus). Atlas is the Wifi-only target known here as "GeeWiz Media". Atlas3G adds to that changes required to include voice/data support (mostly courtesy of Cyanogenmod!). Let's assume if you're reading this, you're interested in Atlas3G.
In the terminal, at the ~/android/platform directory
source build/envsetup.sh
lunch
The "Lunch Menu" (haha Google) will present you with a list of device builds to choose from. You can select by number, or you can type in anything not on the menu. As of this writing, the build we want is #8, full_atlas3g-userdebug. userdebug generates a generally release-quality build, but doesn't odex (pre-optimize) the APKs and has some additional debugging support you wouldn't ordinarily find. You could also type in full_atlas3g-eng for an "Engineering" build or full_atlas3g-user for a "Release" build. I think you'll prefer userdebug most of the time.
Select 8 - full_atlas3g-userdebug
make -j4 rompackage
This will kick off the build. It will take a long time the first time through. The rompackage argument is something I added to AOSP to support the Fascinate. This will build the EDIFY update-zip that I upload for everyone and use to generate the ODIN packages (more on that later). On typical Android devices, you would use otapackage (update-zip install) or updatepackage (fastboot install) instead. Fascinate is a special needs child, so it gets a special needs build process.
Once it's done, provided I didn't forget anything important here, you'll have a full ROM/Kernel package ready to be flashed via Clockworkmod or GeeWiz Recovery in the ~/android/platform/out/target/product/atlas3g folder. It will be named along the lines of full_atlas3g-rom-YYYYMMDD.HHMMSS.zip. Making a package for ODIN involves more steps, but I'll get to that. First I have to tell you how to build a modified Kernel ...
BUILDING THE GEEWIZ KERNEL
The Atlas and Atlas3G repos have a pre-compiled kernel in them that is packaged with the ROM build. This section will describe how to build and include customized versions of that kernel. First step is, of course, to get the source code. Both ROMs share a kernel but due to differences in the ramdisk (initramfs), they are built independently.
In a Terminal, at the ~/android directory
git clone https://github.com/djp952/android-kernel-atlas.git
cd android-kernel-atlas
git branch android-4.1.2_r1 remotes/origin/android-4.1.2_r1
git checkout android-4.1.2_r1
Now the build environment needs to be set up. I use the compiler provided with AOSP to build the kernel as this is how Google does it. If you are using a different compiler, or have put your AOSP tree into a different location, you may have to modify these commands slightly.
In a Terminal, at the ~/android/android-kernel-atlas directory
export ARCH=arm
export SUBARCH=arm
export CROSS_COMPILE=arm-eabi-
export PATH=~/android/platform/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin:$PATH
NOTE: From this point forward, don't close that Terminal, otherwise you will have to execute the environment export commands again.
The kernel is built in three steps. This is necessary because the Fascinate doesn't conform to Android's models and we have to include the ramdisk (initramfs) in the kernel image. The first step is to select which device you are building the kernel for, which in this case will be "atlas3g_defconfig". (The other configuration for GeeWiz Media is called "atlas_defconfig").
make atlas3g_defconfig
This initializes the kernel build for Atlas3G. Since we need to build the ramdisk as part of the kernel, the next step is to generate any loadable kernel module (.ko) files that need to be part of that ramdisk
make modules
The way I have the kernel set up, it will pull the necessary files for the ramdisk by looking at the device "initramfs.list" file, in the AOSP tree. The file that describes the atlas3g ramdisk, for example, is in ~/android/platform/device/samsung/atlas3g. If you examine this file you can see that it lists where all the files should come from, relative to the kernel source root directory. This explains why I went through how to build the AOSP tree before the kernel, the kernel depends on the AOSP build. Provided everything is in the right place, it's time to build the kernel
make
This executes the main kernel build. Should any ramdisk files be missing, it will error out early on and let you know what the problem is. Assuming everything goes well, your kernel will be in the ~/android/android-kernel-atlas/arch/arm/boot directory. It's named zImage and it's the combined kernel/ramdisk required for the Fascinate.
This zImage file can now be flashed directly to the device with Heimdall, packaged up for ODIN, etc. However in order to make it part of your AOSP build and corresponding EDIFY update-zip, we have to copy it into the AOSP tree and rebuild the ROM. It's a bit tedious, and other folks have different and more streamlined ways of accomplishing this, but this method has worked for me.
cp ~/android/android-kernel-atlas/arch/arm/boot/zImage ~/android/platform/device/samsung/atlas3g/kernel
cd ~/android/platform
source build/envsetup.sh
lunch full_atlas3g-userdebug
make installclean
make -j4 rompackage
This set of commands will clean out and rebuild your ROM package with the updated kernel.
CREATING ODIN PACKAGES
While not the most popular way for people to install your ROM, no guide would be complete without describing how to generate the ODIN-based installation packages. I like to provide a "Full Wipe" ODIN package that will take care of resetting the device while flashing the new ROM/Kernel, it's an easy way for people that are comfortable with ODIN to just completely replace the contents of their phone with your stuff. For this section, I'm going to assume that you are using GeeWiz Recovery, version 2.8 or later. Other recoveries will work, but as you may expect I'm most familiar with the one I made and I know for certain it has all the necessary features in place.
The ODIN factoryfs.rfs file must be generated by formatting the SYSTEM volume with RFS and then installing your ROM:
Copy your generated EDIFY update-zip to the SDCARD
Reboot into GeeWiz Recovery
Wipe the device data by selecting Wipe Device Data and then Wipe all User Data (Factory Reset)
Press the HOME key to return to the main menu
Format the SYSTEM volume with RFS by selecting Manage Volumes / Format Volumes / Format SYSTEM / Format SYSTEM [rfs]
Press the HOME key to return to the main menu
Select Install Update Package, and choose your EDIFY update-zip to install
After the installation is complete, reboot the phone by selecting Exit from the main menu. Not rebooting the device after the flash will result in a bad ODIN file more often than not. Trust me on this one.
After the device has fully booted, reboot it back into GeeWiz Recovery. The next step will be to generate a backup of the RFS-formatted SYSTEM volume to ultimately use with ODIN. GeeWiz Recovery can create these by choosing to execute a "raw dump" of the volume:
Select Manage Volumes / Backup Volumes / Backup SYSTEM / Backup SYSTEM [raw dump]
GeeWiz Recovery tries to keep volumes unmounted after it's done working, so the SDCARD must be mounted before the contents can be accessed with ADB:
Press the HOME key to return to the main menu
Select Manage Volumes / Mount Volumes / Mount SDCARD
GeeWiz Recovery will store the backup as /sdcard/backup/volume/SYSTEM-YYYYMMDD.img.gz, so as an example, I might pull it to my home folder with this command:
adb pull /sdcard/backup/volume/SYSTEM-20121022.img.gz ~/
The .gz file will contain a compressed copy of the backup, just open it up, extract the file, and then rename it to factoryfs.rfs. This is the SYSTEM volume for ODIN. There are also a number of other files you can include in your ODIN package to perform various other flash or wipe operations (I'll tell you where to get them, too)
boot.bin - Will replace the primary bootloader. VERY DANGEROUS to include, I strongly recommend against including it.
cache.rfs - Will wipe the CACHE volume; necessary if you want the device to boot into recovery automatically and run a command
dbdata.rfs - Will wipe the DBDATA volume
factoryfs.rfs - Will replace the SYSTEM volume
modem.bin - Will replace the CDMA modem
movinand.bin - Will wipe the DATA, PREINSTALL and FOTA volumes
param.lfs - Will replace the parameter block. Semi-dangerous to include, but required to ensure an initial boot into recovery mode
recovery.bin - Will replace the RECOVERY kernel and ramdisk
Sbl.bin - Will replace the secondary bootloader. VERY DANGEROUS to include, I strongly recommend against including it.
zImage - Will replace the BOOT kernel and ramdisk
To generate an ODIN-compatible tarball, gather the files you want to include and execute the following commands from a Terminal. Replace tarfilename.tar with the name you want to give the tarball, and replace file file file file with the names of the files from the table above you want to include:
tar --format=ustar -cf tarfilename.tar file file file file
md5sum -t tarfilename.tar >> tarfilename.tar
mv tarfilename.tar tarfilename.tar.md5
NOTE: If you rename the .TAR file, it will invalidate the MD5 checksum and you will have to md5sum it again.
OK, where to get the files. You can access a "full stock" ODIN package for the Fascinate, like the EH03 version that is available here on XDA to get copies of all the stock versions of these files. Or, you can use the ones from my ODIN "Full Wipe" package if you'd like as well. My ODIN tarball has a gimmick that you may find useful. If you include my copies of cache.rfs, param.lfs and recovery.bin, the device will initially reboot into recovery and automatically format the CACHE, DATA and DBDATA volumes with the EXT4 file system. It's a relatively simple trick, but an effective one to help improve the performance of your ROM. I also like to provide a "syskernel" tarball that includes only factoryfs.rfs and zImage. The benefit of this is that it will not wipe out any of your user's data. The downside is that the user may be responsible for going into Recovery on their own and executing any steps your EDIFY update-zip would have typically taken care of, like clearing the Dalvik-cache.
==================
For now, that pretty much sums it up! I can expand on this, or perhaps more appropriately compress it (I am a tad verbose!) based on feedback and how useful this little guide ends up being for everyone. Let me know -- PM me or post here in this thread, I'll see it either way!
reserved post
reserved 3
Downloading now. Will reply with the results soon
Just have one question though. I am on a voodoo kernel ie kgb with geewiz 2.9 rom. And I will be using the edify update method to flash the 3.2 rom. Do I need to convert the file system to ext? Or can I just flash it over the existing setup.
Thanks in advance
edit...I flashed the JB rom on the above setup. The phone is stuck at the big X logo. Doesnt seem to go beyond that. So i went back to stock froyo. Then flashed GW 2.8.1. Booted properly. Everything working fine. Next i flashed geewiz recovery & converted files to ext4. rebooted. works fine too. Flashed JB rom. Phone still stuck at the X logo.
Kindly help...
Sent from my SCH-I500 using xda app-developers app
swapnilss said:
Downloading now. Will reply with the results soon
Just have one question though. I am on a voodoo kernel ie kgb with geewiz 2.9 rom. And I will be using the edify update method to flash the 3.2 rom. Do I need to convert the file system to ext? Or can I just flash it over the existing setup.
Thanks in advance
edit...I flashed the JB rom on the above setup. The phone is stuck at the big X logo. Doesnt seem to go beyond that. So i went back to stock froyo. Then flashed GW 2.8.1. Booted properly. Everything working fine. Next i flashed geewiz recovery & converted files to ext4. rebooted. works fine too. Flashed JB rom. Phone still stuck at the X logo.
Kindly help...
Sent from my SCH-I500 using xda app-developers app
Click to expand...
Click to collapse
Let me follow those exact steps and see what happens. Mandatory silly question: did you wipe data after installing the JB rom?
Just to clarify to make sure I do the same thing, you went back to stock Froyo (ED05), not stock Gingerbread (EH03)?
It will sit at the X logo for quite some time after flashing the ROM, since it has to dalvik all the apps. "Quite some time" in this case means like 3-5 minutes though. It does take much longer than Gingerbread to do this, but it's not some craziness like half an hour.
:crying:
edit: If I can't duplicate this, I can post a kernel update where debugging is ON by default so we could use ADB to see what it's hanging up on, but I will totally understand if you don't want to go through all that effort. Been there!
Odined back to stock. Loaded full wipe 3.2 and everything is golden. MMS, WiFi etc works great.
Did have to restart before WiFi would start. ROM is a little laggy at first but once it settles performance is on par with other JB Roms:thumbup:
Thanks Mr.GeeWiz: looks great for a "beta"
Edit: speakerphone works great also, sweet^o^
Sent from my SCH-I500 using xda app-developers app
I still think in overall the ROM is laggy.
WiFi requires restart each time you switch it off.
Whatsapp is not working after SMS code verification.
Thanks DJP952
i decided to give this a try. everything works great. wifi did not require a reboot for me. camera, mms, wifi all work great. a little sluggish getting started, but pretty stable nonetheless. great work DJ. thanks
djp952 said:
Let me follow those exact steps and see what happens. Mandatory silly question: did you wipe data after installing the JB rom?
Just to clarify to make sure I do the same thing, you went back to stock Froyo (ED05), not stock Gingerbread (EH03)?
It will sit at the X logo for quite some time after flashing the ROM, since it has to dalvik all the apps. "Quite some time" in this case means like 3-5 minutes though. It does take much longer than Gingerbread to do this, but it's not some craziness like half an hour.
:crying:
edit: If I can't duplicate this, I can post a kernel update where debugging is ON by default so we could use ADB to see what it's hanging up on, but I will totally understand if you don't want to go through all that effort. Been there!
Click to expand...
Click to collapse
Hi djp,
I forgot to mention that I have bought the handset from Reliance (mobile service provider in India ). And that puts a limitation on me as I am not able to wipe the data dalvik and cache whenever I flash my phone to a new rom. If I do the data wipe I lose my 1x/3g Connectivity and I cannot restore it (tried various options like data fix files, apn restore etc etc) unless I flash the stock rom from Reliance (EK10 Froyo. No official gb rom for India yet ). Hence whenever I flash roms I do not wipe data. But in spite of that I have never faced any problems. Infact now the number of user apps is close to 100 and I can still flash any touchwiz rom (geewiz 2.8, 2.9, tsm resurrection and 2.2 etc without any problems. I am in no way promoting my method of not wiping but I have no other choice.
With the given restrictions that I have, please advise me how and what I can do to successfully flash JB rom. Currently there are no user apps in my device so clearing dalvik should not be a problem.
Sent from my SCH-I500 using xda app-developers app
swapnilss said:
Hi djp,
I forgot to mention that I have bought the handset from Reliance (mobile service provider in India ). And that puts a limitation on me as I am not able to wipe the data dalvik and cache whenever I flash my phone to a new rom. If I do the data wipe I lose my 1x/3g Connectivity and I cannot restore it (tried various options like data fix files, apn restore etc etc) unless I flash the stock rom from Reliance (EK10 Froyo. No official gb rom for India yet ). Hence whenever I flash roms I do not wipe data. But in spite of that I have never faced any problems. Infact now the number of user apps is close to 100 and I can still flash any touchwiz rom (geewiz 2.8, 2.9, tsm resurrection and 2.2 etc without any problems. I am in no way promoting my method of not wiping but I have no other choice.
With the given restrictions that I have, please advise me how and what I can do to successfully flash JB rom. Currently there are no user apps in my device so clearing dalvik should not be a problem.
Sent from my SCH-I500 using xda app-developers app
Click to expand...
Click to collapse
Ah, I see your point. When you had problems with activation, were you wiping data using Recovery or using the "Factory Reset" option in the OS? The latter, at least the Samsung version of it, will indeed nuke your activation. However, using Recovery to do it *shouldn't* affect anything. The activation stuff is stored in some secret location that recovery doesn't affect. I honestly have no idea where it's even stored, I used to think it was on the "EFS" volume, but as it turns out it's not!
I've never spent any real time trying to figure out a more surgical way to wipe data other than nuking the DATA and DBDATA partitions completely. Unfortunately, I don't really have the necessary knowledge to be able to do it any other way. While I'm relatively confident that wiping data through Recovery won't hurt, of course I cannot be 100% certain of that.
I apologize that I don't know enough about the non-Verizon models to be more confident in a recommendation for you. From what I know of the SCH-I500 CDMA, wiping outside of the Samsung OS, changing the modem version, or using the evil "EFS Clear" option in ODIN has never affected activation for me.
Sorry sir. Without a wipe, this one's not going to work. Just too far removed from the stock ROMs.
I can duplicate the Wifi issue and am looking into it. For me, it just took a REALLY long time for it to turn on, like 10 minutes. I think I know what I've done that might cause this and hope to fix it Getting the logs now.
edit: I think I see what the problem is, not sure why it hasn't been an issue with the "Media" version. I have to dynamically load and unload the Wifi driver to prevent bad things from happening, this isn't the usual way it's done. The OS is set up to start the Wifi "supplicant" automatically, when it probably shouldn't be. The supplicant can't load if the wifi driver isn't up yet. Sometimes it works, sometimes it doesn't, and when it doesn't Wifi will be hosed until the OS sorts it out. I have two solutions to try, the first is to see how Android behaves if I don't allow the supplicant to be started as part of the "main" service class, the second is to figure out that aforementioned bad thing and do it more properly. I'll get it. Sorry for the bug
Thanks for trying this guys! I never expected it to be as good as the "big" ROMs, and I wish I could do something about it being so ungodly slow for a while. It seems to pick up and work properly after all the apps have been updated and it's had a chance to do all the Google backups and whatnot that it wants to do.
One problem I saw yesterday for the first time that you might need to watch out for ... The battery TANKED in a matter of 2 hours for some reason. It looks like Google Search went off the reservation. I've also seen "GPS Status and Toolbox" destroy the battery if you don't close it all the way (long-press HOME, then swipe it away).
Oh, one cool feature we have now ... "Take Bug Report". Check in Settings/Developer options to see it. What this does is collect all kinds of logs and information about the phone and make an e-mail out of it. The default sends it to your GMail account. It's about 3MB, but it will be nice to have something everybody can use to gather logs for problem resolution rather than asking folks to hack around in ADB. So, if you run into weirdness, you can click that button, wait a while and watch scary "shell has been granted superuser permissions" pop up a lot, and you'll ultimately end up in GMail with something you can send you me or post parts of here! Great that Google added that in an accessible way finally!!
For the folks having trouble with turning Wifi on and off, I have an experimental/test patch for you. This patch will replace the GeeWiz 3.2 kernel with an updated version that changes the ramdisk/initramfs such that the wifi services are not started until Android requests them to be started. It may affect Wifi and Bluetooth Tethering, but my testing of the change here for both showed no ill-effects:
GeeWiz 3.2.1 Wifi Patch [Experimental] [EDIFY update-zip]
REMOVED: Please use official patch in the DOWNLOADS section of the main post
NOTE: You will be asked to re-opt-into the Google Location service on the first boot, this is normal. I clear the "Google Services Framework" app on any kernel change now to avoid the well known Jelly Bean issues with losing connection to Google Services when you alter the kernel. This may have been fixed with JZO54K, but why risk it when all you have to do is click "Agree"
You may have to reboot once more after installing this to clear up the Wifi on/off problems so that the Android settings are synchronized with the changes. If after a second reboot this does not solve your problem, please let me know!
Rollback: This change can be rolled back by installing the EDIFY update-zip for GeeWiz 3.2 again on top of it without wiping data. I can also package/provide a more specific rollback that only undoes the changes if necessary.
Please let me know if this solves your Wifi issues or not, so that I can either post it as a primary patch for GeeWiz 3.2 (and GW Media 3.2) or take another crack at solving it Thanks!!!
djp952 said:
Ah, I see your point. When you had problems with activation, were you wiping data using Recovery or using the "Factory Reset" option in the OS? The latter, at least the Samsung version of it, will indeed nuke your activation. However, using Recovery to do it *shouldn't* affect anything. The activation stuff is stored in some secret location that recovery doesn't affect. I honestly have no idea where it's even stored, I used to think it was on the "EFS" volume, but as it turns out it's not!
I've never spent any real time trying to figure out a more surgical way to wipe data other than nuking the DATA and DBDATA partitions completely. Unfortunately, I don't really have the necessary knowledge to be able to do it any other way. While I'm relatively confident that wiping data through Recovery won't hurt, of course I cannot be 100% certain of that.
I apologize that I don't know enough about the non-Verizon models to be more confident in a recommendation for you. From what I know of the SCH-I500 CDMA, wiping outside of the Samsung OS, changing the modem version, or using the evil "EFS Clear" option in ODIN has never affected activation for me.
Sorry sir. Without a wipe, this one's not going to work. Just too far removed from the stock ROMs.
Click to expand...
Click to collapse
Hi!
Wiped data dalvik and cache & now I am on JellyBean. Thanks djp952. :good::good::good:
This Rom looks great and apart from the Wifi issue ( havent got time to update my phone with the patch for wifi issue as yet) which takes some time to start or sometimes just rebooted my phone altogether, everything seems to work fine. Had a problem verifying Whatsapp but used their "Verify by Call" method and now its working fine too. Battery life seems good to me as of now. Liked the inbuilt BLN.
Sadly, as i mentioned before, i lost my 1x/3g connectivity (nothing to do with this Rom) and thats Ok for a day or two till i try & figure out something to enable it again. By the way, i have always done the wipe through recovery only. Never used the factory reset option in settings menu. And that means the 1x/3g settings get wiped out the moment I wipe Data (note: wiping dalvik & cache does not affect it).
Anyways , looking forward for more developments on this rom from you.
edit... The stock gallery does not seem to show all the files available in that folder. I have 1400 plus pics in that DCIM folder and the stock gallery shows 1000 or sometimes 500 only.
QuickPic
swapnilss said:
The stock gallery does not seem to show all the files available in that folder. I have 1400 plus pics in that DCIM folder and the stock gallery shows 1000 or sometimes 500 only.
Click to expand...
Click to collapse
We are a little off topic, but... I too have had nothing but problems with the stock Gallery application... not loading at all, not showing pictures, generally being grumpy (okay, so I get that way too sometimes), etc.
Try Quickpic (http://market.android.com/details?id=com.alensw.PicFolder) , it's a free app that is a gallery replacement (ad-free too!). Just make it the default and you should be set. If, for some reason, you don't like it... Just uninstall and revert back.
As for the Jellybean ROM... too sweet! I love having an original Galaxy S with JB running on it! I get questioned all the time what phone I have, because it's running the latest Android build and doesn't look like any out there right now.
Sent from my SCH-I500 using xda app-developers app
I'll load up some huge amount of photos and have a look at Gallery. I could switch from using the Google Nexus version to the AOSP, if it shows any improvements. One bonus we could get there is that I enabled widescreen photos in the AOSP branch Didn't include it for various reasons, one I recall was that it would crash if you tried the "face detect" option.
I'll have a look -- maybe it can be fixed! I also have to download this "Whatsapp" that people are using ... never heard of it What does it do?
Thanks as always for the feedback guys! Glad it's going pretty well thus far
FYI for any aspiring developers, I've started making a "HOW TO" guide for building GeeWiz from scratch in Post #2:
http://forum.xda-developers.com/showpost.php?p=33011164&postcount=2
I've gotten as far as how to make the AOSP ROM and compile the kernel. At minimum, I need to add how to make the ODIN files as well, but maybe later. Depending on level of interest, I can go into as much as anyone wants there, short of how to make actual code changes (but I could try to help offline). I think describing how to get from source to the flashable files is a good first step, I'll see how it goes from there
DJ, you should link this on the home page of GeeWiz 2.9, so more folks can get this. Also, I think you should name it JellyWiz...
Can I ask what this is ?
AndroidGee209 said:
Can I ask what this is ?
Click to expand...
Click to collapse
JellyBean for the Fascinate, with GeeWiz recovery and kernel
---------- Post added at 03:53 PM ---------- Previous post was at 03:51 PM ----------
where can i find the compass?
Brickbug Aftermath: Speeding up the Galaxy S2 i9100, S2 AT&T i777, S2 Epic 4G Touch d710 and Note n7000
UPDATE: KERNELS CAN TRIM FAT PARTITIONS
contrary to what has been said in this thread and elsewhere, the S2 TRIM kernels could always trim FAT partitions. the problem is that the FAT file system implementation does not support batch trimming (ie: fstrim), but the fact that the DISCARD mount option has always been supported on FAT has eluded us all. the mainline commit that introduced the option is here, and the corresponding code in CM's repo is here.
this means that it would probably be a good idea to add DISCARD to the default mount options of the internal sdcard in CM. deleting files from internal storage would probably become slower, but the expectation would be that overall performance should increase. the performance issues related to queue flushing that plague non-queued TRIM commands should not be a big problem in this case, since the sdcard is used mostly for media (few big files without multitasking access).
UPDATE: VICTORY !!!
2016-03-02: after two years of tests and discussions, folklore, FUD and evidence, @Lysergic Acid finally took the plunge and merged! TRIM is now part of the official CM 12.1 and CM 13.0 kernels, and this project can at last be retired, yoohoo!!! CM 13 users now enjoy TRIM out of the box, but users of CM 12.1 builds older than Match 2016 as well as CM 11.0 users continue to require a separate TRIM kernel.
this thread is dedicated to Entropy and the brave users who risked their devices to run the very first TRIM tests.
IMPORTANT NOTE FOR USERS
i am tried of lazy users sending private messages to me instead of reading the thread. i am especially tired of users asking over and over on PMs whether TRIM is safe. if you read the threads you would know: TRIM is completely safe on every supported device, stop asking! and please, never PM technical questions to anyone on XDA unless you already know the guy.
DOWNLOAD FROM -> HERE
IMPORTANT NOTE FOR KERNEL DEVELOPERS ONLY
you should not blindly merge these changes into your kernel. doing so can result in unrecoverable bricks!!! you need to check that certain patches are already merged in your kernel before enabling TRIM. please follow these steps; you can get help from this post. please contact me when in doubt, let's not revive the slumbering brickbug monster from hell, thank you!
UPDATE: CM 13.0 kernels are now available!!! (for CM 13.0-supported platforms only: i9100 and i777.)
UPDATE: several enhancements in new kernel batch:
CM 12.1 kernels are now available!!! (for CM 12.1-supported platforms only: i9100 and i777.)
kernels can now be flashed with the official, restricted cyanogen recovery that is bundled with CM 12.1.
rom-independent kernels: kernels are no longer dependent one-to-one on specific official CM builds (they might work with other roms too), and their names no longer reference a specific CM build.
although there are no official CM 11 builds for the i777, thanks to rom independence CM 11-based kernels for that device are now available.
CM 11 i9100-to-i777 cross-flash kernels for the i777 may now work with other i9100 roms besides official CM.
UPDATE: Dic 25, 2014: a holiday present!!! as kernel maintainers swiftly acted to patch PFBug, @Gustavo_s took the plunge and merged TRIM support in his latest kernel. i have verified that his kernel is as safe as mine regarding TRIM. finally a more mainstream kernel is getting this functionality, hopefully i will be able to discontinue my kernels soon!
UPDATE: great news, we have fixed FPBug!!! fixed TRIM kernels are online!
UPDATE: this project now supports all roms and kernels!
if you are not running CyanogenMod M snapshots, please see this post.
this project restores TRIM capability to CyanogenMod kernels for the Galaxy S2 family of 4210-based devices: i9100, i777, d710 and n7000. TRIM is needed to avoid "aging" of the state of the eMMC, the internal flash storage, that eventually slows the device to a crawl. TRIM functionality is built into android 4.3 and later. however, due to historical and safety concerns, TRIM capability was removed from the CM kernels for these devices (and from most if not all other AOSP-based kernels).
an in-depth discussion of this matter, including safety, risks and current state of the kernels for various devices, can be found in the main project thread. you can review that content if you are curious. get the source for this project: patches and patcher script are here (git) and base system here (repo). for instructions on how to recreate my kernels from source, see this post.
STATS: Nov 5: 500+ kernel downloads (latest version only).
Oct 1: 250+ kernel downloads (then-latest version only), top 5th thread in its forum (ThreadRank).
PROJECT STATUS: testing still needed on MAG2GA TRIM bug-affected devices before TRIM patches go mainstream. IMHO, TRIM patches are ready to be merged into mainstream kernels. kernel maintainers please read the warning at the very top of this post!
UPDATE: kernel wifi issues fixed! thanks to invaluable help from @mparus. also, ART works just fine.
What to expect
some users see big changes while others do not. there are many different eMMC models with different firmware versions embedded in these devices, and it is clear that some are faster than others. it is even possible that some eMMCs may have firmwares that completely ignore trim commands. following are some benchmarks and comments submitted by users.
@defecat0r run before-and-after benchmarks and packed it all in this neat graph (thanks so much!):
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
@defecat0r also says: "I've been dicking around copying stuff back and forward, factory resetting and restoring cwm recoveries while on this kernel for a day now, if this fix was going to trigger superbrick i'm sure it would have done it by now. As far as i'm concerned this is safe as houses. [...] This is the biggest thing to happen to these devices since i don't know when!" (post)
@smoke2tun got better results: "My phone is blazing fast". he says: "The phone is really snappy and responsive. [...] After runing Antutu v5.1 the overall score is 17816. On NeatRom the score had an average of 11000." (post)
@Roxxors: "My phone had become so unbearably slow I was about to toss it in the garbage, [...] I'm coming from NeatROM 4.1.2, and let me tell you something, after installing C11 M9 with this kernel, my phone is FLYING." (post)
@|Vyp|: "Nice work, the device is flying now." (post)
@bihslk: "OMG! Installed CM11 M10 and your TRIM. Phone is flying now,,, WoW" (post)
@burninghouse: "i installed it and i can say only one word....."AWESOME"... My s2 is blazingly fast with same battery life" (post)
@dirtyhewr: "Omg... I don't think my device has ever been this fast... No lags at all" (post)
@Dudebowski: "[...] the increase in write ops nearly doubled! Regardless of the numbers for proof, this trim along with the floater fix [ed. note: FPBug] has made this device enjoyable to use again for the first time in years. The change in responsiveness after trim is night and day." (post)
thank you so much for the feedback and benchmarks guys!!
When things do not work
then again, some users do not get big improvements. check out the case of @desvariando.
speculation about these cases can be made. TRIM failing to provide advantages can be attributed to one of two causes:
when the fstrim command is run on some devices, it reports success but runs in zero time instead of taking the usual couple of seconds it takes on most devices. it looks like samsung disabled ERASE/TRIM support in some eMMCs, as a stopgap measure while they researched the issue further and before they output a final fix. if your eMMC trims in zero time, there is probably no realistic way to ever trim it. once your device gets slow, it can never be rejuvenated. if you fall under this group, and you have not yet ever filled the device's internal memory and your device still performs well, i would reduce the internal sdcard partition in size asap and leave a healthy sized area of 2GB inaccessible. this overprovisions the eMMC and ensures that it will never ran out of untrimmed space (assuming that the disk area you are leaving out is in fact still trimmed from factory). UPDATE: so now i know of a way to trim these untrimmable devices. it is extremely dangerous though (unless you have JTAG access to the eMMC). these eMMCs have a command to resize their boot partitions (boot0/boot1). these partitions are treated differently from all others by these modules. you can think of them as separate, safe, small, virtual disks; even if you write all over the main disk, you will never touch these partitions. also, wear leveling on the main disk will never move data around on these partitions. contrary to data on the main disk, once you write something here, it stays written forever (until you write something else). because they are treated differently, the eMMC needs to know their size. for versatility there is a non-standard command that will resize these partitions, and as a side effect it will repurpose the rest of the flash as the "main disk", creating all of its FTL structures from scratch. this full, low-level reformatting will fix a brickbug-damaged eMMC and will also trim an untrimmable device. the trick is to resize the boot partitions to some strange value, then resize them back to original size. all data everywhere will be lost, including the bootloaders, and this is why it is so dangerous. these phones will brick unless there are proper bootloaders and friends in place (though with JTAG access you could restore all this data). so the procedure would go like this: boot into recovery, make backups of all partitions you care about (bootloaders, EFS, etc), resize boot0/boot1, resize them back, and restore the needed partitions. but if anything goes wrong before you finish... you have a brick! because it is so dangerous, AFAIK this procedure has never been attempted to fix a brickbugged S2, much less to just trim one. but it has been carried on successfully on devices that boot from alternative sources when their eMMC is wiped, check it out here.
your device still had a reasonable amount of trimmed space when you installed this kernel and trimmed, and was not in need of trim. this can happen if you never filled the device's internal memory throughout its entire lifetime, or if you trimmed your device recently without knowing it. you could have trimmed by using the stock 4.1.2 kernel (which is TRIM-capable) in two ways: by wiping data from android or recovery, or by using an app such as LagFix.
otherwise, your device should be more responsive and use less battery after trimming. the need for trim is a well established reality that no FTL-based flash storage can escape.
STOP!!! DRAGONS AHEAD!!!
in theory there could be risk of hard-bricking your device forever. i believe this risk to be non-existent, based on reasons i detail in the aforementioned thread, and also based on recent experience: many people are already using these kernels without any kind of incident. however, the standard disclaimer applies: you accept full responsibility for what happens to your device.
READ and FOLLOW the instructions carefully.
Downloads
for the supported devices, you will find IsoRec-compatible CyanogenMod-based kernels here. (old kernels without IsoRec support can be found here. yet older retired kernels without FPBug fix are still available here.) note that for some supported devices, no releases or M snapshots are currently being produced. for those devices i can produce kernels based on known 'stable' nightlies if users ask.
A word about CyanogenMod 10.1.3
UPDATE: great news, we have fixed FPBug!!!
there are no CM stable releases for 4210-based devices after CM 10.1.3. the sad truth is that the kernel for these devices is broken. this affects all roms, not just CM. there seems to be some unidentified defect in the hardware itself, and no workaround for it has been implemented in the kernel so far (if such a thing is even possible). after years, @cgx finally observed the bug in action and now we at least know what we are up against. it is nasty as hell: random stack corruption. in layman's terms, any process can randomly misbehave, crash, be corrupted, corrupt data, etc... all bets are off, anything could happen. and it looks like this might never be fixed.
for whatever reason this was not much of a problem in the CM 10.1.3 days. these days, with a much more advanced and demanding android, the bug is real trouble. most people find that the last reliable CM version for their 4210-based device is 10.1.3 (including the CM team itself). i made kernels for this version, find them in the downloads section.
NOTE: the CM 10.1.3 kernels are untested. do take a nandroid! and please post your results.
Instructions
prerequisites: you need to already be running a fully official version of CyanogenMod supported by this project. (i mean fully official: dual booters, alternative kernel/recovery users, etc are not invited to this party.) you will replace your current official CM kernel with the patched, EXACT SAME VERSION kernel from this project.
download this app and run it to check if your device is affected by hardware bugs. root is requested but not needed for this test. do not trust the app's verdict! instead use the reported eMMC model name and the firmware revision (fwrev) to look up your eMMC in this table.
is your eMMC model an MAG2GA? if so you are affected by TRIM bug. WARNING: this configuration is untested. my kernels should be safe but they have never been tested on this particular eMMC, so risk cannot be completely ruled out. please read this post and decide whether you would like to test. testers are needed! i believe this is the last remaining piece of evidence needed to establish the general safety of trim on this family of devices and start pushing for its inclusion in the standard kernels, which is the ultimate objective of this project. UPDATE: things are looking much better, see this post. testing is still needed though, please help. UPDATE: MAG2GA eMMCs with fwrev 0x0E can be found in d710 devices and were tested to TRIM without problems. i personally believe this configuration to be safe.
are you affected by WL Bug? impossible. according to the available data, no 4210-based device has ever been produced with this eMMC... SO YOU MUST BE MISTAKING. please double check your situation; then post. (in any case, this bug is supposed to involve data corruption only, and not bricking.)
are you affected by Brickbug? my kernels contain samsung's fix for this bug, but samsung's fix was never exercised in practice with TRIM. i will accept ONE volunteer to test. i do not want more than one device to brick if the test fails. know that testing can potentially brick your device beyond repair. i would prefer someone with a compromised S2 (eg: lost IMEI, cracked screen) to do the first test. please post your willingness to test on this thread (include eMMC and fwrev). UPDATE: many people affected by this bug are already using my kernels without incidents. i personally believe this configuration to be safe.
if you are not affected by the previous bugs, you run no special risks by flashing my kernels.
you should start on a supported official CyanogenMod; if you are not already running it, flash it now and test it.
optional: as an extra safety step, back up your EFS and store it OUTSIDE your phone. you should have done this years ago! you never know when you might need that backup.
optional: preferably no apps should be moved to the internal sd card (check 'apps' in settings). this could slow the device a bit, but is no problem otherwise. note that apps moved to the EXTERNAL sdcard can cause BIG SLOWDOWNS.
optional: make sure you have 20% (or at the very least 10%) free space in your internal 2GB /data partition (where apps are normally installed). you will not notice speed improvements unless/until you have free space in /data.
optional: if you have been on official CM (including kernel) for a long time, and this is the first time you are going to trim your device, please contribute benchmarks. install Androbench and run all benchmarks, it takes just a few seconds. in the history section you can see most if not all results in a single screen; please take a snapshot for your before-and-after comparison.
make a nandroid backup. if you need to back out of the change for whatever reason, you will be happy to have it.
download the appropriate kernel for your CM build (includes CWM-based recovery). flash it without wiping. (at any time you can reflash official CM without wiping or upgrade to a newer CM -loosing TRIM support, of course.)
reboot.
install the LagFix (free) app from xda (the market version is declared to be incompatible with the i9100). go to the lagfix tab, check the 3 partitions, and tap on run. grant root access. the 3 fstrim operations should be successful ("partition was trimmed" means success).
UPDATE: there is a replacement app for LagFix called Trimmer that has several advantages over the former: is fully free, can schedule TRIMs, and is compatible with Android 5.
alternatively, instead of using lagfix you can run one of these commands (these are better because they also trim /preload):
# on the phone in the terminal app:
su -c "fstrim -v /system; fstrim -v /data; fstrim -v /cache; fstrim -v /preload"
# on your PC if you are connected to the phone via adb:
adb shell su -c "fstrim -v /system; fstrim -v /data; fstrim -v /cache; fstrim -v /preload"
reboot.
optional: contribute benchmarks if you qualify. run Androbench again to take an 'after' snapshot and share your before-and-after shots below.
your device should now run FAST... profit!
Please donate hardware to test
i do not have any of the supported devices to test, i am developing blind. i would gladly accept an i9100 with a cracked screen as a test bed if you can send it to an address in USA or Argentina (or any other supported device).
But wait, there's more...
Automatic trimming
android 4.3 and later should trim all writable file systems each night during charging automatically (/cache, /efs, /data and /preload). you do not need to invoke fstrim or lagfix manually again. if you want to be extra tidy you can invoke lagfix after each flash of a CM upgrade to trim /system (which is normally read-only).
because of this offline auto trimming, android 4.3 and later should not mount partitions with the discard mount option (which implements online trimming whenever space is freed), but CM does anyway. this is a bug that slows down the device and i have uploaded a patch to CM's gerrit. my kernels fix this as of Sep 14 2014.
if you use CM 10.1.3 (android 4.2.2), you might be thinking that you need to regularly trim the file systems yourself (you could use scripts or lagfix premium for automation). but as of Sep 14 2014 my kernels mount /cache, /data and /preload with the discard option, meaning that freed space on these partitions is immediately trimmed (which, again, slows down the device compared to offline trimming but is better than no trimming at all). so you only need to invoke lagfix after each flash of a CM upgrade to trim /system if you want to obsess about it. (the /efs partition is not mounted with discard; call me superstitious.) btw, i made the /preload partition writable (it is normally read-only in CM 10.1.3) so you can trim it and/or use it for whatever purpose you want. i could create 10.1.3 kernels without the discard mount option for those who wish to roll their own periodic trim feature; just ask.
The internal sdcard partition
the majority of the phone's flash is devoted to the internal sdcard partition which is formatted in a vesion of FAT. unfortunately the linux kernel file system driver for FAT is unable to trim its free space. some people format this partition to ext4 for performance and safety reasons (google). if you do that, you can fstrim it.
The preload partition
these devices have 0.5 GB ext4 /preload partition (also called "hidden"). in CyanogenMod it is unused and should be empty (you can check with the file manager). you can manually fstrim this partition (open a terminal on the phone and type: su -c "fstrim -v /preload" or from the PC via adb: adb shell su -c "fstrim -v /preload") or format it from my recovery to increase the trimmed free space in your eMMC, effectively increasing its over-provisioning by 0.5 GB. this makes the eMMC faster and extends its useful life.
UPDATE: i have removed the trim-on-format functionality (partition wiping) from the kernel patches, and thus all future kernels. there are no safety concerns with the previous kernels, but there can be problems if someone uses my patches to build a complete ROM (as opposed to just a kernel, as i have been doing). please refer to the commit for details. [Oct 3]
Adjusting partition sizes
you can repartition your phone to better distribute available flash space. i recommend vestigial /preload (unless you want to go back to stock roms later), 1 GB /system (the original 0.5 GB /system is too small for android 4.4 and gapps; 0.75 GB is enough, but the Nexus 5 comes with 1 GB, so i guess google expects it to keep growing), 6 GB /data (of which you should always keep 2 or 1 GB free to provide the eMMC with trimmable free space -remember the FAT partition does not trim), and the rest (about 8 GB) used for the internal sdcard. you can format the internal sdcard as some FAT or as ext4. (but windows does not understand ext4, but there is MTP... google!)
you can use ODIN (windows-only) or heimdall to repartition. @Roxxors contributed a nice partitioning how-to that you should read. note that he embedded my M9 kernel in his ODIN files. to create a file with the right kernel for your needs, read this.
here are some PIT files (these files are for the i9100 16 GB only, but you can use PIT Magic to roll your own):
0.5 GB system
0.75 GB system
1 GB system, 3/4/6 GB data
1 GB system, 8 GB data
1 GB system, 4 GB data, small preload
1 GB system, 6 GB data, small preload <-- this PIT is buggy!
(see attached file for a replacement i made; includes a script to repartition from linux using heimdall.)
in general, 2 GB, or even 1, of trimmable free space (ie: free space in the /data partition) will probably be more than enough to speed up your device, with rapidly diminishing gains over that.
UPDATE: due to a bug in CM, the recovery is unable to format the /preload partition. formatting is needed after repartitioning. to manually format, open a terminal on the phone and type: su -c "mkfs.ext2 /dev/block/platform/dw_mmc/by-name/HIDDEN" or from the PC via adb: adb shell su -c "mkfs.ext2 /dev/block/platform/dw_mmc/by-name/HIDDEN" (you can also use other commands such as mke2fs and mkfs.ext2.)
PLEASE NOTE: this is not a partitioning thread!!! please DO NOT seek partitioning help in this thread. please post in an appropriate thread instead. this thread is for KERNEL ISSUES ONLY. thank you!
XDA:DevDB Information
BrickbugAftermath-i9100, Kernel for the Samsung Galaxy S II
Contributors
Lanchon
Source Code: https://github.com/Lanchon/BrickbugAftermath-SGS2
Kernel Special Features: CyanogenMod kernel with TRIM support
Version Information
Status: Stable
Created 2014-08-10
Last Updated 2016-04-17
TRIM On Other Roms And Kernels
TRIM on custom roms
when running any non-trim enabled kernel, significant speed benefits can be obtained by overprovisioning the eMMC. as long as a portion of the eMMC is in the erased state (trimmed) it will perform well, even if the kernel is not able to trim. this can be seen for example when the device is new: non-trim kernel and still the device runs nicely. as time goes on, normal usage causes the eMMC to be written all over, reducing the amount of trimmed space to zero and killing performance. this situation can be avoided in two ways: 1) by using a trim-enabled kernel that will trim space once it is no longer used by files, or 2) by setting aside an area of the eMMC and never write to it, effectively keeping it in the erased state. this second option is called overprovisioning in SSD parlance.
those of you wanting to run official CM kernels, CM nightlies, or other custom roms altogether can still obtain most of the benefits of a trim-enabled kernel without one by overprovisioning your eMMC. the stock partitioning of the 4210-based devices includes an 0.5 GB /preload partition that is just perfect for the job.
Requirements:
you have not repartitioned your device and shrank the /preload partition to enlarge other partitions.
your custom rom does not use the /preload partition. (CM does not, and I do not know of any that does... but google!)
you are not using dual-boot or other mods that use the /preload partition.
NOTE: if you have shrunk /preload and enlarged /system to 1 GB you can still follow these steps to overprovision using the free space in /system, but you will need to redo them every time you flash a new rom. otherwise, if you have an 0.5 GB /preload, you can do these steps once and just forget about the whole thing (until you flash something to the /preload partition, that is).
Instructions:
NOTE: please read step 9 now and decide if you want to use a root file manager to delete everything in /preload before you start or if you want to try to format the partition with your current recovery.
READ THIS POST IN FULL. find out which bugs your eMMC has if any, and decide whether to run the risk of trimming.
download to your device the newest trim-enabled kernel for your particular device from here.
download to your device a recovery-flashable copy of the kernel that you are currently using. (or else make a nandroid backup in step 6.)
if you want, download to your device the recovery trimmer script attached to this post. (see step 11 for more information.)
reboot to recovery.
make a nandroid backup if you do not have a flashable copy of your current kernel on your device. (make sure your nandroid is compatible with CWM-based recoveries.)
flash the trim-enabled kernel.
in the advanced section, choose reboot recovery. now you are temporarily running a trim-enabled kernel.
in the mounts and storage section, choose format /preload. (make a nandroid backup first if unsure of its contents.)
NOTE: it has been reported that format /preload does not work. this is a bug in CM's recovery. you may want to adb shell to the device to delete all files and folders under /preload, including those hidden. free space in this partition will remain trimmed when you later use the phone so it is important that most of the partition be empty after this step. (bug report)
still in the mounts and storage section, mount (if necessary) the following partitions: /system, /cache, /data and /preload.
choose one of these two options:
attach your device via USB to your PC, open a terminal, and type adb devices to verify that your device is reachable and authorized. (if it is not, under linux type adb kill-server; sudo adb devices to troubleshoot the issue; under windows try restarting the adb server from an administrator console.) in the terminal type adb shell "fstrim -v /system; fstrim -v /data; fstrim -v /cache; fstrim -v /preload" to trim. for each partition, fstrim should output a message stating the number of bytes trimmed; this indicates success.
flash the attached recovery trimmer script. you will not have any indication of success using this method. (make sure you have mounted the applicable partitions in the previous step!)
flash your old kernel back or, equivalently, restore your nandroid. (you can advance-restore only the boot partition if you want.)
reboot and profit.
TRIM on rooted stock android 4.1.2
this is beyond the scope of this project, but still some people may be interested.
Instructions:
make sure you are rooted.
WARNING: MAKE SURE YOU ARE RUNNING STOCK ANDROID VERSION 4.1.2 (THE RELEASE, NOT A LEAKED VERSION) OR YOU WILL DESTROY YOUR DEVICE DUE TO BRICKBUG!!!
READ THIS POST IN FULL. find out which bugs your eMMC has if any, and decide whether to run the risk of trimming.
WARNING: MAKE SURE YOUR EMMC IS NOT AFFECTED BY TRIM BUG OR YOU WILL DESTROY YOUR DEVICE!!! if you have trim bug, you must not trim on a stock kernel, end of story.
also, it is assumed that release (not a leak) 4.1.2 stock kernel contains this patch and thus is brickbug safe. but there might be different versions, and there is no way to be sure if the corresponding source code was patched by samsung, so...
WARNING: IF YOUR EMMC IS AFFECTED BY BRICKBUG, THE POSSIBILITY HARD BRICKING YOUR DEVICE CANNOT BE COMPLETELY RULED OUT without access to the kernel source code. proceed at your own peril, or better yet, switch to a custom rom/kernel.
install the LagFix (free) app from xda (the market version is declared to be incompatible with some 4210-based devices). go to the LagFix tab, check the 3 partitions, and tap on run. grant root access. the 3 fstrim operations should be successful ("partition was trimmed" means success). alternatively, those with busybox installed can try issuing the fstrim commands themselves. in particular, you must do this to trim /preload. you can also look for the fstrim command in the private files of LagFix.
UPDATE: there is a replacement app for LagFix called Trimmer that has several advantages over the former: is fully free, can schedule TRIMs, and is compatible with Android 5.
reboot and profit.
NOTE: i assume there is little free space in /system and /preload in stock roms, so most benefits will come from trimmed free space in /data. this space will get overwritten in time so you will need to periodically trim.
Recreating My Kernels From Source
i have been wrongly accused of not providing full source code to my kernels. to counter this accusation i am providing step-by-step instructions on how to exactly recreate any of the kernels published in this project from source. to start, all you need to know is the filename of the kernel you want to recreate. then simply follow these steps:
identify and obtain the CM release that corresponds to the kernel based on the kernel filename. example:
kernel: kernel-cm-11-20140915-NIGHTLY-Lanchon-TRIM-20140916-n7000.zip
CM release: cm-11-20140915-NIGHTLY-n7000.zipnote that nightly releases are not kept for long in CM's download servers. that is why i mirror all relevant nightlies right beside my kernels in the downloads section.
extract the build manifest (/system/etc/build-manifest.xml) from the CM release zip file.
using the manifest, checkout the source code corresponding to the release to ~/android/system by following these instructions.
identify the version of the patches that corresponds to the kernel based on the kernel filename. example:
kernel: kernel-cm-11-20140915-NIGHTLY-Lanchon-TRIM-20140916-n7000.zip
branch: cm-11
date: 20140916
tag to match: cm-11-20140916
identify the corresponding tag in my github repo and checkout its tree to ~/android/brickbug/BrickbugAftermath-SGS2. if no tag matches exactly, use the tag in the same branch that sports the closest earlier date.
run ~/android/brickbug/BrickbugAftermath-SGS2/scripts/repo-patch apply to apply the patches.
(repo-patch apply functionality used to be provided by standalone script apply in old versions.)
build the kernel using these instructions.
finally, you can run ~/android/brickbug/BrickbugAftermath-SGS2/scripts/repo-patch reset to unpatch your source tree.
(repo-patch reset functionality used to be provided by standalone script reset in old versions.)
Sh*t...
erdal67 said:
Sh*t...
Click to expand...
Click to collapse
lol brickbug
well someone will have to the guts to try. if you read the main thread (very long), i argue that it is probably safe to run my build in your phone... but then, there's only one way to know for sure
erdal67 said:
Sh*t...
Click to expand...
Click to collapse
Got the same Revision (19) according to the cm table this Rom could! But not must brick our device?
empulse92 said:
Got the same Revision (19) according to the cm table this Rom could! But not must brick our device?
Click to expand...
Click to collapse
i'm sorry you are affected. i personally think it would not brick (for reasons explained in the main thread, you are invited to chip in).
but i could brick! there's risk.
we will never know until somebody tests...
Lanchon said:
i'm sorry you are affected. i personally think it would not brick (for reasons explained in the main thread, you are invited to chip in).
but i could brick! there's risk.
we will never know until somebody tests...
Click to expand...
Click to collapse
I think i may give it a try... Unsure if i should usw another pit? Got 2gb (stock) for now you suggestet to use 4or 6 GB? I got some Mainboards hat home with destroyed imei chips, seems to be good testers if the chip is the same :highfive:
Another question: is the fw Version of the chip upgradeable via Odin vor heimdall? Is it possible to acces the Software used by this chip?
empulse92 said:
I think i may give it a try... Unsure if i should usw another pit? Got 2gb (stock) for now you suggestet to use 4or 6 GB? I got some Mainboards hat home with destroyed imei chips, seems to be good testers if the chip is the same :highfive:
Click to expand...
Click to collapse
boards with lost IMEIs? that would be great to test!!! no big loss in the worse case.
don't bother with the PIT files. just follow the main instructions. this is to test if it TRIM works without bricking in those chips. if you later want to set up a phone for real use, you can try resizing the partitions (i would for my phone).
exactly the same chip! VYLOOM 0x19 :victory: (date differs , 06/2011 but i guess this wont make a big difference at least )
edit: bootin...:fingers-crossed:
edit 2: succesfully booted,
empulse92 said:
exactly the same chip! VYLOOM 0x19 :victory: (date differs , 06/2011 but i guess this wont make a big difference at least )
edit: bootin...:fingers-crossed:
edit 2: succesfully booted,
Click to expand...
Click to collapse
cool!! thanks!!!
and? did you use lagfix?
did u trim /sdcard?
Lanchon said:
cool!! thanks!!!
and? did you use lagfix?
did u trim /sdcard?
Click to expand...
Click to collapse
i did dont know if there are errors if trim isnt supported or not but for now... see yourself
note : play store says lagfix app is incompatible with this device i got the app from xda
http://forum.xda-developers.com/showthread.php?t=2104326
Click to expand...
Click to collapse
empulse92 said:
i did dont know if there are errors if trim isnt supported or not but for now... see yourself
note : play store says lagfix app is incompatible with this device i got the app from xda
View attachment 2891398
Click to expand...
Click to collapse
thanks! yes i'll update the app link then. those trims were successful, and yes it shows errors when you try to trim and the kernel doesn't support it.
i guess now you should use that phone and see if it bricks... for now its looking like the chances of bricking are going way down.
could you do two more tests?
try to trim /sdcard (steps in my first post)
then enable ART (debugging menu) and and see if it boot loops or not.
thanks!
no error when trimming sdcard... should i wait some more before trying art?
empulse92 said:
no error when trimming sdcard... should i wait some more before trying art?
Click to expand...
Click to collapse
great! did the trim sdcard command took some time, like a second or two? or did it end absolutely immediately, like a no operation would?
no, everything checked ok, you can try ART. i think it should work. if it doesnt, wipe data from recovery (i think you are using an empty phone anyway, right?)
there was no delay after using the command.. just as you said, as if nothing happened. this is why i was wondering^^ but still not sure about this
yep the phone is empty, but i cant get into recovery or download mode .. time to set up adb
edit: device offline-.-'
edit 2: i am retarded and forgot to press the home button :')
edit 3: alrighty, now it boots but after wiping its still dalvik cache vm
empulse92 said:
there was no delay after using the command.. just as you said, as if nothing happened. this is why i was wondering^^
yep the phone is empty, but i cant get into recovery or download mode .. time to set up adb
edit: device offline-.-'
edit 2: i am retarded and forgot to press the home button :')
Click to expand...
Click to collapse
hmmm... i've read somewhere the android shell sends stderr to limbo. i just tried to fstrim /sys on my nexus and not a word, exits immediately. on my linux PC it says "fstrim: /sys: FITRIM ioctl failed: Inappropriate ioctl for device".
i'll look into this further. meanwhile, are u testing ART?
EDIT: i dont know why no error is printed. but on android, if you fstrim with -v option you get text if successful:
[email protected]:/ # fstrim -v /system
/system: 0 bytes trimmed
[email protected]:/ # fstrim -v /data
/data: 2399477760 bytes trimmed
[email protected]:/ # fstrim -v /sys
1|[email protected]:/ #
so if you do fstrim -v /sdcard and you get no output, then the kernel is unable to trim FAT32. if this is the case, it would pay to find a alternate solution to this in the long run.
enabling art forces bootloop, formatting data reverts back to dalvik :silly:
no chance to use art for now^^
edit: here's a logcat but i'm not sure if it shows a normal boot or the art bootloop
https://drive.google.com/file/d/0Bw86veXkn-fiZ2FnU3lqdkFuWVE/edit?usp=sharing
edit 2: another screenshot (dont be confused i didnt change the time zone yet)
empulse92 said:
enabling art forces bootloop, formatting data reverts back to dalvik :silly:
no chance to use art for now^^
edit: here's a logcat but i'm not sure if it shows a normal boot or the art bootloop
https://drive.google.com/file/d/0Bw86veXkn-fiZ2FnU3lqdkFuWVE/edit?usp=sharing
edit 2: another screenshot (dont be confused i didnt change the time zone yet)
View attachment 2891493
Click to expand...
Click to collapse
thanks!
assuming official M9 has working ART, there must be some trouble with my build setup. my OpenPDroid build has the same thing, it is not related to TRIM. oh well...
your screenshot clearly shows there is no TRIM support for FAT32
i will think of what to do next. in any case, if you turn off ART and flash this on your working phone (with 20%+ free space in your internal partition) you should notice a big improvement in responsiveness and diminished lags. (a friend told me "feels like a different phone", but maybe he is exaggerating.) i still warn against doing it! i would exercise the internal storage on this phone for a while, installing big apps then deleting them, flashing the rom a couple more times, and using LagFix to trim all partitions.
or you can make a backup of your current phone and restore it here, then lagfix, and see if the increased speed justifies the risk. its your call...
for now i have nothing else to ask you to test. thank you very much!!! you've been amazing help!!!
using this on my daily phone now :good:
empulse92 said:
using this on my daily phone now :good:
Click to expand...
Click to collapse
oops! are you sure??? i hope nothing bad happens...
after LagFix trimming and rebooting, how do you feel the phone in the way of responsiveness?