Tips & Explanations

From JKuloWiki
Revision as of 20:45, 27 February 2012 by Jkulow (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Rom Flashing/Bricking

It is VERY important to know what you are doing when flashing a ROM to your phone. It isn't difficult to HARD BRICK your phone if you do not understand what changes on your phone between ROMs. The key thing to read and understand is how Android devices behave upon boot. I recommend reading this thread for detailed explanations on the many ways to brick your phone.

The first thing to try and avoid are ROMs that alter your boot loaders. It is getting harder and harder to find ROMs that leave your boot loaders alone so this may not always be possible. Just remember if you ever have any doubt on whether your boot loaders have been changed you should ALWAYS try and use a tool like Odin3 OneClickDownloader (for the Captivate only). This reverts both your Primary Bootloader and your Secondary Bootloader to stock which alleviates most problems that cause hard bricking.

A quick and dirty breakdown of how the Android OS boots up.

  1. Boot Rom. Phone powers on and searches for something to boot to.
  2. First stage a.k.a. Primary boot loader (PBL) is found and loaded in to memory (boot.bin). The PBL can only do so much so it searches for a way to expand its capabilities. (This is where hard bricking can occur.)
  3. Second stage a.k.a. Secondary boot loader (SBL) is given control to expand the capabilities of the system to run larger chunks of code and access the phones hardware completely. SBL is loaded in to memory (sbl.bin). (This is also where hard bricking can occur)
  4. The Kernel is then given power by the SBL. The Kernel is known as the OS for all intensive purposes. The kernel handles all of the core processes and activities of the Android system. (This is where soft bricking happens. (boot loop))

Hard bricking occurs when you have a damaged, corrupted or mismatched boot loader. A hard brick is UNRECOVERABLE as recovery (by average users) requires the ability to at least boot to the secondary boot loader to enter download mode. In other words, if you damage your primary boot loader you logically cannot proceed to the secondary boot loader phase which is where the ability to access download mode becomes available. Damaging the secondary boot loader results in the same fate of an unrecoverable hard brick as the secondary boot loader phase needs to finish in order for you to enter download mode to perform recovery steps.

Lag Fix

The Android file system is known as RFS which stands for Root File System, there is a process known as FSYNC that the root file system calls upon exit which is a very safe and secure way of behaving. When this command is called, it is telling a driver to write a particular piece of data to a file. Now, this is not to say FSYNC is to blame for slow response times on your device. In all actuality it is the way FSYNC is used in RFS and how the memory module/chip known as MoviNAND handles that, and every, command.

MoviNAND is referred to as a "smart" disk which means it knows how to manage itself, for the most part. You could say it cleans its own house. When a "dumb" disk is issues an FSYNC command, the disk will instantly write the data exactly where the kernel has told it to and not ask questions. In the MoviNAND chip, it queues everything up and handles each command or process sequentially to make sure it does exactly as it is told and that there is no conflicting data in the spot the kernel says to write to. This equates to a long time in regards to computations, it can sometimes take several seconds before the chip returns. Since RFS performs a “sync-upon-exit” this means instant slowdowns in your phone's processing ability until all queued processes or commands have completed.

When you perform a “lag-fix” mod, this (generally) converts your root file system to the Ext4 file system. By converting to Ext4 the ‘sync-upon-exit’ issue is resolved. The reason this works is because the Ext series of file systems is more efficient at file system grouping which results in fewer calls to the MoviNAND chip which means fewer processes the chip needs to complete before returning. However, because the “sync-upon-exit” process is removed, it is possible for you to lose data if you removed the battery because some data that is written to a file has not had a chance to be written to disk yet. This equates to less security when using Ext file systems in place of RFS.

For a more detailed breakdown then please visit this thread.