Boot Loader: Where to start - General Topics

I have a little bit of experience about how to write application for M68EZ328, I have also ported MySQL to Embedded System now i am doing work on bootloader & I have completed following task:
1) Bootstrap Mode Operation
2) Boot Record Format
i- Data B-record Format
ii- Execution B-record Format
3) How to initialize target system by using Initialization program
4) Usage of Instruction Buffer
5) S-Record Output Format
i- S-record format
ii- S-record Types
iii- S-record Creation
iv- How to write a program which is capable of converting S-record to B-record as per target system's requirement and vice versa.
6) User programming Modal
7) Addressing Capability
i- Instruction Format
ii- Effective Addressing Mode
Now i would like to write a bootloader program for a new board resemble with M68VZ328. I have initialized my board. Now i need support to go ahead; how to write a bootloader program, what type of infrastructure 'll be needed, what sort of technique to be implement, where to load kernel image to be execute, how to interact with serial port (Internal register address).
Kindly inform me the best way to learn those entire factors which is able to show me the success key.
--
-------------------------------------------------- -------------------
IMRAN SHABBIR
Research Associate (CS)
COMSATS Institute of Information Technology,
H-8, Johar Campus,
Islamabad, Pakistan.
Ph: +92-51-9258481
Ext: 289"

Related

nandflash,how to write full page(528bytes)

hi everyone;
i have a jtag facility, msm6125 chip phone. boss need me read/write whole nand flash, page size 512+16;
i can read; but how to write oob 16 bytes? thkx for reading this.
msm6500 nand cmd
An interrupt will be generated upon each operation, except on the soft-reset, which
is done immediately.
000 : Software reset (of NAND flash controller . Ongoing operation will abort, NAND
controller will be forced into idle, and the configure register is reset to power up
default value.)
001 : page_read (Transfer one page of data from the NAND flash to the SRAM
buffer. The NAND flash page address is provided by the NAND_FLASH_ADDR
register.)
010 : flag_read (This command reads one byte from the spare area of the NAND
flash. The page address and byte address are all provided by the
NAND_FLASH_ADDR register. Some NAND flash makers, e.g., SAMSUNG, use
the spare area to mask bad blocks upon shipping. After a flag_read operation, a
reset operation is suggested before issuing a page_write command.)
011: page_write (Transfer one page of data from the SRAM buffer to the NAND
flash. The page address is provided by the NAND_FLASH_ADDR register.)
100 : block_erase (Erase one block of NAND flash memory. The block address is
provided by the NAND_FLASH_ADDR register.)
101: ID_fetch (Read the NAND flash maker ID and device ID. (This ID information
can be used to determine the actual size of the NAND device.)
110: status_check (Check the NAND flash device status.)
111: reset NAND flash memory (This reset-operation is suggested upon power-up.
This reset-operation is also suggested after a soft-reset command abort an ongoing
operation.)
Click to expand...
Click to collapse

incl. ROM now: WM 6 updated Tornado kitchen with SDHC + 28/25MB total/avail storage

This kitchen is a continuation of the Nitrogenious kitchen released at XDA-devlopers.
Nothing has changed from the tools side, only subtle adaptations and altered content.
Thanks go to :
all the experts at XDA-developers (too many to list)
Nitrogenious for releasing his WM6 kitchen and the superb WM6 package contained therein.
The original kitchen is found here: http://forum.xda-developers.com/showpost.php?p=2150690&postcount=1
Mind that usage description has to be taken from there!
Cotulla for publishing the OMAP850_SDHC.dll that can handle SDHC cards and llnhhy for putting the crucial REG setting in his published package for the Tornado.
More details are discussed here: http://forum.xda-developers.com/showthread.php?t=576164
SGregory for revealing (at least I found it there) that "format BINFS" can actuall take a parameter that sizes the BINFS partition and thus opens the path to gain device storage space if the ROM gets smaller!
More details on saving space are outlined here: http://forum.xda-developers.com/showthread.php?t=491240
- Sir.B and geistteufel for the Squeezer batches for UPX. XDA-Develpoer threads are:
original: http://forum.xda-developers.com/showthread.php?t=481880 and post of geistteufel (the one used in this release): http://forum.xda-developers.com/showpost.php?p=3540501&postcount=92
Disclaimer:
This is for educational purposes only!
There will be no support for the published content!
Enjoy and contribute.
Warning:
Mind that from the "cooking" or "kitchen" point of view this is for sure an old base and possibly more elaborate tools and definitely newer OS versions exist. The produced files should not be able to "brick" your device if you correctly set the Image Name to "OS" in the last step of the cooking process. IPL or SPL should never be written unless you know exaclty what you do - the kitchen only cooks the OS part! Writing incorrect content to the IPL or SPL area will brick your device for sure, so be careful!
Motivation:
This effort was only done to get a running stable ROM with SDHC support included that occupies as little storage space as possible
still having mandatory elements on board
filling the remaining space with useful tools
Space saving strategies (order of benefit):
outsource parts to SD card where possible (.NET CF 3.5)
compress files (.exe and .dll) that are not stored as modules with UPX where function permitts.
remove files that are not needed for any function
remove media data (ringtones, pictures) and leave only the bare minimum
resize media data where possible to further decrease size
not done, but possible:
- remove optional packages (additional color schemes) (25k)
- remove empty packages (15k)
- summarize registry tweak packages to just one additional package (edit the .rgu) (few kB)
About UPX and builtin BINFS compression:
My experience is that the BINFS compression shrinks a set of example files (.NET CF 3.5 files that reside in the \Windows path) to about 49% while UPX'ed they only take 32% of their initial size. So on average you may gain 17% of the initial filesize in your ROM. The larger the file, the better is usually the gain.
Mind that UPX will only compress exe/dll files (even if they may be named differently, see Total Commander's *.tfx) and does not compress exe/dll that depend on .NET. It works luckily on the .NET CF core parts itself.
You should not compress (even if compression works, these DLLs will not load later):
resource DLLs
menu extension DLLs (context menus)
Updated and altered content:
added SDHC support by replacing the OMAP850_SDHC.dll with an SDHC capable version initially created for the StrTrk. So far there are no negative impacts visible.
altered the titles of the options to indicate the space they take - also UPX'ed size
moved the oemstartup.dll and the relevant pictures to the folder where the optional sounds already resided
added German T9 to the English T9 - so both is installed in the system if you select this. Mind that an additional language is not eating much space (~70k)
added the SafeInboxExtension as an own option to add, removed the InboxExtension from the combined "Group SMS + ..." menu
put moBlue to the latest version (2.1) and adapted rgu content.
added an option for registry changes called "tobbie GUI tweaks" that sum up everything that I think is useful (smaller menus, fonts, scrollbars, value for gamma).
updated the TotalCmd to the latest released version
created several additional packages from the previous default content (CeleTask, ClearType Tuner, ClockOnTop, ComManager, Dopod SIM Manager, .NET CF 3.5, OMAPClock, OxiosAlarms, OxiosMemory)
added a new package for .NET CF 3.5 where the GAC_* files have to reside on SD card. The complemtary ZIP containing the files to copy on SD card are located in the "_Changes" directory.
added the GPSID Settings tool to the GPSID directory
included the SP1 fixes supplied by Nitrogenious (FakeCursor not included)
changed several tweaked menus in the settings -> system tweaks
added options for volume setting of the initial beep and voice tag to the Voice Tag menu in system tweaks, changed category of the [HKEY_CURRENT_USER\ControlPanel\Sounds\VRecBeg] from "Notifcation" to "System" so that only the sounds sent form the VoiceTag are audible when the System sound volume is set to 0.
completely UPX'ed the SYS\MMSCAMCLKSTK *.exe and *.dll (except 2)
replaced the htcmidi.avd with the WM5 version to get back good midi playback,
added the HTCSourceflt.dll (from Nitrogenious SP1) to get midi playback in wmplayer
removed two large files from this directory which are nowhere referenced (CameraRC_*.dll).
updated WM5torage to the latest version (1.90), already setting suitable defaults.
fixed default settings for A2DP
Directory and contents
added a batchfile (you may want to edit) where the %SystemDrive% can be set to any value. This allows to install the kitchen on any drive you like and not on C:\ (the normal systemdrive) as it was mandatory. Mind that the scope of this %systemdrive setting is limited to the batch execution only. You can put the whole environment on a large RAMdisk (~380MB required) - this speeds up the cooking dramatically! A large RAM disk is available from "[ QSoft ] Qualitative Software" (1 year trial for the lite version) - see here: http://members.fortunecity.com/ramdisk/RAMDisk/ramdriv002.htm .
added a subdirectory "_Squeezer" where you find the UPX compression set "Squeezer" also published at XDA-developers (readme contained there). I have used this set to batch compress many files before putting them to ROM.
added a directory "_Changes" where you find the compressed and original versions of the files in equally named subdirectories OEM and SYS like in the WORK path. So in case you want to go back to the non-UPX-ed version they are there. Continuing the UPX-batch directory logic (2_Backup, 3_Compressed) there are further ones (4_removed and 5_changed) to document the changes done to the original content.
The rest of the kitchen is identical to the one Nitrogenious had released.
Download here: http://www.mediafire.com/file/xdiz2xzmote/Tornado_Kitchen_v09_by_tobbbie.exe
Quick Start:
- Unpack to C:\
- read cooking guide at Nitrogen's thread (see above)
- using defaults you get a ROM with: http://www.mediafire.com/file/z3ynij5ynzd/default-settings.gif
- available storage 27,97MB, free after 1.st boot 24,8MB
Correction: If you want to use the moBlue package, please edit the RGU file and add a blank line at the end. Using notepad will ensure that the file stays in unicode format.
Correction-2 (14.10.2010): You will experience that while WMP is playing the backlight will not go off as normal. This can be fixed by replacing the HTCWMPPlug.dll in the \windows directory on the device or in C:\Torn\_Changes\SYS\MMSCAMCLOCKSTK in the kitchen with the attached file.
Please make sure that your device is "SuperCID" before entering the "Format BINFS command. See post 3.
added 20100314: (edited 20100504)
Despite it is really extremely easy to cook your own ROM with the kitchen, let me give you a head start with your old Tornado. I have cooked the default settings to a ROM and added all tools that you need to step from a stock Tornado to the cooked one in a single archive.
Download it from here: http://www.mediafire.com/file/njm040ttoxm/_tobbbie-tornado-WM6(SDHC-NetCF_on_SD).exe
Unpacking it you will find a directory structure:
Code:
_tobbbie-tornado-WM6(SDHC-NetCF_on_SD)
├───1 prepare security
│ ├───1 HTCUnlock
│ └───2 SDA_ApplicationUnlock
├───2 prepare for custom flash
│ └───Utils
├───3 flash latest Radio and SPL
├───4 format BINFS 1b00000
├───5 flash ROM
└───6 copy NetCF to SD
└───Windows
Follow the actions in the directories one-by-one:
You only need to do steps 1 and 3 if you come from an official ROM but Step 2 (lokiwiz) needs only be done once per device.
If you flash another cooked ROM you can start from step 4.
Attention: In case you did not notice yet - the following procedures will completely erase all content that you stored on the device (email, SMS, MMS, ToDo, Contacts - simply everything) - the device will be as if it comes out of the box. So back up your data before you do this!
Here is what to do in detail, how and why:
Prepare security: This means that the restrictive program execution privileges have to be set less firm to allow step 2 to run later.
Connect your Tornado to the PC and let Active Sync connect. First run HTCUnlock-CVS.exe in the directory 1 HTCUnlock. This will install a program on your device. Run the installed program there and restart the device.
After the device has reconnected to Active Sync, on the PC run the program SDA_ApplicationUnlock.exe in the folder 2 SDA_ApplicationUnlock. It should confirm "succesfully unlocked".
Now the device is ready to receive the "SuperCID" that allows to flash any ROM to it, regardless of Operator or Vendor limitations. To be on the safe side later, please enter on the device *#06# and note down the IMEI that the device reports - you will need it later.
This needs only be done once per device - it is a permanent setting that survives all ROM updates.
Go to the folder 2 prepare for custom flash and
make sure there are no files *.bin left from previous device's activities
then execute Lokiwiz.bat. It will prompt you with 4 options:
Code:
U. Unlock
L. Lock
C. CID Unlock (SuperCID)
Q. Quit
--------------------
Type the letter and press Enter:
Input "C" <enter>.
It will copy a program (itsutils) to the device and it should ask you for permission to execute - grant execution and let the batch file continue. You should find 2 new files beside the Lokiwiz.bat (lock-backup.bin and cid-unlocked.bin). Move them to a safe place immediately and do not repeat the procedure or call another option!
Be careful to label these files unambigously (best is to append the device's IMEI to the name - get it with *#06# before and do not use the IMEI printed on the label of the device - as restoring a wrong *.bin file to a device will kill the GSM radio access (Message: Data Crashes, please contact your... when trying to connect to the network with a SIM card inserted).
Now the device is prepared to receive custom ROMs.
Let's first put the last available Radio ROM and SPL (Secondary Program Loader) to the device. Go to the directory 3 flash latest Radio and SPL and execute ROMUpdateUtility.exe. After successfull update the device will restart in the old OS, nothing has visibly changed - you could still use the device as it is, all your data are still there.
Now the preparations start to erase the old OS and flash the new one.
Deactivate USB connections for the Active Sync
Switch off the device and disconnect from USB
Press Camera Key and keep it pushed down while connecting the USB cable to the PC - wait until the 3-color screen appears and release the camera key.
Start ttermpro.exe in directory 4 format BINFS 1b00000
Select Serial and Port USB
Press <enter> in the terminal window, you should get prompt CMD>
enter info 2 <enter> you should see something like:
Code:
Cmd>info 2
GetDeviceInfo=0x00000002
+ SD Controller init
- SD Controller init
+StorageInit
CMD55 failed
+ SD Controller init
- SD Controller init
+StorageInit
CMD55 failed
HTCSSuperCID ' HTCE
Cmd>
The last line must show HTCSSuperCID ' HTCE.
If you see anything else there (e.g. HTCSVODA0504 㱍dHTCE - which is for an Austrian V1240) the lokiwiz in step 2 above did not work correctly. Still you have not destroyed anything (hopefully) - so to get the old OS start up again, enter ResetDevice <enter> - the device will restart and boot again. Think about what went wrong in the previous steps.
The lokiwiz batch file and the tools behind it are very powerful and can kill the GSM radio access of the device. Be careful with the *.bin files and keep those of different devices clearly apart.
In case you see HTCSSuperCID ' HTCE then you can pass the point of no return (after this the OS and all your data are deleted from the device) and enter at the prompt format BINFS 1b00000 <enter>. (The value 1b00000 depends on the ROM size, so if you use a different ROM, the value may also be different.) After a few seconds the prompt returns and the partition where the OS was stored is cleaned up now. The device will not boot beyond the 3-color screen in this state. You need to flash the new OS in the next step - but before this enter ResetDevice <enter> - the device will restart and return to the 3-color screen.
Terminate the tterm.exe, you will not need it any further.
Re-activate USB connections in Active Sync - you may forget it later.
Enter the directory 5 flash ROM and execute ROMUpdateUtility.exe. The procedure looks the same as in step 3 but takes a little longer. Do not get nervous as the time at 100% extends a few minutes. The device will reboot and bring you to the new OS.
The SD card that shall be used in the device needs to have the NetCF 3.5 files copied to the directory \Windows finally. This is NOT on the device but on the card - you can copy it on the PC while the sd card is in a card-reader or when the device has is mounted, there the path is \Storage Card\Windows
If the device had a SIM-Lock and it rejects your SIM, go to the lokiwiz.bat (again move out all *.bin files) and select "U" for SIM Unlock - again move the bin files in the directory to a safe place (but you should never need them). Mind that the "lock_backup.bin" is just a copy of the current encrypted area in the device. So this file is different after each step you completed before. Worse: if you do not save the FIRST lock-backup.bin you can never go back to this state.
Mind that lokiwiz.bat has worked for me on a Telenor Sim-Locked nordic ROM CID-locked QTEK 8310, so it should work for any other device as well. If you get the dreaded "Data Crashes..." message and your restore of the correct lock-backup.bin did not help either - your last resort is the SIM Unlock service here: http://imei-check.co.uk/c600_unlock.php. It costs you some bucks, but they seem to re-create the encrypted area with the matching IMEI of your device putting it in a SIM-unlocked and CID Unlocked state. Cheaper than buying a new device.
After you have sucessfully flashed your ROM - maybe you try cooking one yourself?
The selected default settings fill the ROM up to the last few hundred bytes. Adding options will surely jump over the next MB border and your ROM uploading preparations will have to format BINFS with a larger size.
If you have not read it elsewhere yet, the standard sequence to uplad a ROM is:
1.) cook ROM (OS part)
2.) determine size and format BINFS accordingly
more see this thread: http://forum.xda-developers.com/showpost.php?p=3439787&postcount=1
3.) upload ROM
If you start from scratch - so your device is still "untouched" by any custom ROM, you must prepare your device to allow the loading of a custom ROM. This happens in several steps to overcome the various security levels that try to prevent this:
Application unlock the current operating system. Look for "SDA Application unlock" this runs on the PC and remotely unlocks (via the Active Sync Connection) the security of the Windows Mobile operating system. This allows tools to run that you need for the next step.
Super-CID your device (and check if it worked!). Look for "lokiwiz" ZIP file in the forum here. Despite orginally created for the "Wizard" model, it also works for the Tornado in all respect, so it does the Super-CID and it does the SIM Unlock. I did it myself on a QTEK 8310 with a Nordic ROM and SIM-locked to Telnor.
To check if it worked, connect the device in Bootloader mode to the terminal program and enter "info 2" (without the quotes). It has to show HTCSSuperCID ' HTCE
Do not care about SIM lock yet, you can do that anytime later if necessary.
Good luck!
Thanks!
Thanks a lot. Nice work. Very useful. Could you please post one with a PRO rom, preferably the 6.5 version? Or at least the guidelines to make one?
I will not cook any further - this is why I released the kitchen. The strategies to save space are outlined in detail, so other cooks can take them and incorporate to their ROMs.
For me WM6 is sufficient - I don't need the "goodies" that came after that.
Thanks!
Oh fine. Thanks anyway. What is the perceived space saved from this method? And is there any performance hit?
I've seen that UPX'ing has a lot of performance boost so I'm wondering whether it can be made only to the packages or is it applicable to the exe's and large dll's from the CABs too. Since there are a few applications, which even when added later, install to the device memory directly. In these cases, UPX'ing might be highly beneficial in reducing the size as well as giving a speed boost. Any info on this?
Well, indeed you may think that UPX-ing will decrease performance as the file must be decompressed before running - but the opposite is the case!
you save space (most if installed, a little if in ROM - due to BINFS compression that is there anyway)
you get faster file-read time: This pays for especially well for large files (opera, office, acrobat, TomTom and alike). This will by far gain more than you loose for decompression (which goes directly to memory).
Looking at usual read-speeds of about 1MB/sec and an assumed 10 times faster decompression speed to memory, my feeling is that for speed reasons it will pay best for LARGE files (card and memory installed). Mind that after the file is read and loaded to memory, still the application needs to initialize itself. The last step is the same, no matter if UPX-ed or not.
If you tweak the bits for memory saving on the device it is no harm for anything smaller as well. Usually I stop UPX-ing below 50kB in size, but to have the ROM fit in the MB-frame I wanted to achieve I also had to UPX some smaller files as well. Just compare the directories of Nitrogenious' kitchen release and mine.
Hi,
Thanks for kitchen !
Sorry, I'm a novice in ROM cooking (I just modified a bit a ROM for my HTC Touch, long time ago, but I got no problem with flashing ROMS on HTC devices )
So I got a few questions/remarks.
1. I tried to build a custom ROM, but I got an error after selecting options.
I checked log file (a:\Torn\WORK\temp\log.txt) and I found following message :
Failed to parse value name HKEY_LOCAL_MACHINE\Software\hejhej.org\moBlue!!!
InitRegistry FAILED in file ".\Registry\37771312-772c-4ff9-a0a1-b555ad54a025.rgu" within a few lines of line 10.
ImportFromPackageListStrict: (RGUComp) !ERROR failed importing ".\Registry\37771312-772c-4ff9-a0a1-b555ad54a025.rgu"
wmain: (RGUComp) !ERROR failed building DEFAULT hives
If I uncheck "MoBlue", all is OK, so I think MoBlue package is corrupt.
2. When building with default option, what values to put in nb2nbf (CID and start address) ?
I used same as http://forum.xda-developers.com/showpost.php?p=2150690&postcount=1 (82040000 for start adress and ORG_0401 for CID)
Is this OK?
(my phone is an Orange SPV600, CID unlocked, so I think I can put any value for CID)
3. I didn't really understand how to change ROM size. I checked your thread, but I'm still in the dark.
In nb2nbf, in size column, I got "33357824" = "0x13E20248".
So I used "format BINFS 014000000". Is the the way to go ?
Thanks for answers.
Answers!
1. Even I'm unsure about that.
2. Yes. Just select the OS option and it will fill the address by itself.
3. Yes. That is the method I follow. AFAIK, convert the bytes into it's hex equivalent and choose the nearest <higher> hex number with 5 0's at last.
And from what I understand from his post, if you have a ROM with 29.1 mb size, either reduce it to (29 mb - 64k) or add some apps and increase it to (30mb - 64k), to make the optimum use of the available space.
Hi AlainL,
...will have to look after the moblue part - strange, possibly the wrong format of the file (not unicode stored). The content should be ok. I fixed it after updating from the old moBlue inside the old kitchen to the 2.1 version copying the Registry content of the moBlue branch.
Regarding the address it is easy: when you select "OS" and click in the address field, the address is selected automatically - this is the right one.
Your assumption on the format BINFS <size> is correct. This is the way to format it. But your calculation is wrong. The Hex size of your value is 1FD0000 and thus you have to format with 2000000 or your device will not boot after flashing.
The solution to the moBlue problem in the .rgu is very easy.
Edit the .rgu file and add a blank line at the end - that's all.
Editing .rgu files
Just to be on the safer side:
Don't forget to save it in the Unicode format too. Turn off word wrapping while editing .rgu files.
They are all unicode - so if you edit with notepad it should keep this format.
Special attention is required when adding "Multistring" values to the registry. The can be imported as hex - and this hex code must be in unicode format, so 2 bytes per character.
So when exporting the values from the registry to add them to an .rgu package you must take care of this. Took me some tries until I had the .NET CF 3.5 with separated GAC_* package running.
tobbbie said:
Your assumption on the format BINFS <size> is correct. This is the way to format it. But your calculation is wrong. The Hex size of your value is 1FD0000 and thus you have to format with 2000000 or your device will not boot after flashing.
Click to expand...
Click to collapse
Hi
Thanks all for your answers.
I used the right number.
I just made an error while writing in this thread ("0x13E20248" = "333578824").
This cooking works very well.
I just got a problem, maybe someone can help me.
I added Esmertec Java and installed opera mini 4.2, opera mini 5 beta 2 (latest) and opera mobile 10 beta 2 (latest too).
All is OK with 4.2, but with 5b2 and 10b2, I can't pass license agreement screen, because I can't click on "Accept" button (nor "exit" one), neither with left or right menu button or with cursor.
I thinks it's Opera's fault, but if anyone got a suggestion ...
Finally, I got a question :
Now, I'm using a SPV C600 (Orange), and it doesn't have WiFi.
I plan to buy either a XPA1240 or Qtek 8310 (used, quite cheap), but I need to know if WPA is supported.
I can't check by myself, cause every time I try something related to WiFi, I end with an error "Driver not loaded".
I do not cook java in the device but have it installed on SD card - along with the midlets it will take later. The package I use is called "JBEDROSE" (20080813.2.1) and comes from the Vox forum. I have no problems using later versions of Opera there (including 5ß2). I suspect the accept requires a network connection to the opera server (WIFI or AS), so maybe this is your problem?
The WLAN support WEP, WPA, WPA2 and should also cover hidden SSIDs (but I don't use it). The Reg-Tweak "optimal performance for WLAN" is actually putting the WLAN in a mode that will NOT do continuous transmission (and drain your battery real fast - like in WM5) but in a mode that saves battery without affecting performance.
The prices for used 1240 or 8310 are rising at ebay currently
tobbbie said:
I do not cook java in the device but have it installed on SD card - along with the midlets it will take later. The package I use is called "JBEDROSE" (20080813.2.1) and comes from the Vox forum. I have no problems using later versions of Opera there (including 5ß2). I suspect the accept requires a network connection to the opera server (WIFI or AS), so maybe this is your problem?
Click to expand...
Click to collapse
I tied both with AS or via EDGE/GPRS connected (when loading EULA, netwok is required).
It looks like Opera 5b2 and 10b2 didn't recognized both menu button.
I will still do some tests.
tobbbie said:
The WLAN support WEP, WPA, WPA2 and should also cover hidden SSIDs (but I don't use it). The Reg-Tweak "optimal performance for WLAN" is actually putting the WLAN in a mode that will NOT do continuous transmission (and drain your battery real fast - like in WM5) but in a mode that saves battery without affecting performance.
Click to expand...
Click to collapse
Thanks, great
tobbbie said:
The prices for used 1240 or 8310 are rising at ebay currently
Click to expand...
Click to collapse
Because of your excellenet kitchen ?
Opera 5ß2 works on my Jbed (non cooked as I wrote). The opera 10ß2 is native WM - but said to not support smartphones (non-touchscreen) well, so I stick with Opera-mini for the occasional browsing I do there.
Now the default settings are contained in a ready cooked ROM - enjoy!
Appended to the first post:
added 20100314: (edited 20100504)
Despite it is really extremely easy to cook your own ROM with the kitchen, let me give you a head start with your old Tornado. I have cooked the default settings to a ROM and added all tools that you need to step from a stock Tornado to the cooked one in a single archive.
Download it from here: http://www.mediafire.com/file/njm040ttoxm/_tobbbie-tornado-WM6(SDHC-NetCF_on_SD).exe
Unpacking it you will find a directory structure:
Code:
_tobbbie-tornado-WM6(SDHC-NetCF_on_SD)
├───1 prepare security
│ ├───1 HTCUnlock
│ └───2 SDA_ApplicationUnlock
├───2 prepare for custom flash
│ └───Utils
├───3 flash latest Radio and SPL
├───4 format BINFS 1b00000
├───5 flash ROM
└───6 copy NetCF to SD
└───Windows
Follow the actions in the directories one-by-one:
You only need to do steps 1 and 3 if you come from an official ROM but Step 2 (lokiwiz) needs only be done once per device.
If you flash another cooked ROM you can start from step 4.
Attention: In case you did not notice yet - the following procedures will completely erase all content that you stored on the device (email, SMS, MMS, ToDo, Contacts - simply everything) - the device will be as if it comes out of the box. So back up your data before you do this!
Here is what to do in detail, how and why:
Prepare security: This means that the restrictive program execution privileges have to be set less firm to allow step 2 to run later.
Connect your Tornado to the PC and let Active Sync connect. First run HTCUnlock-CVS.exe in the directory 1 HTCUnlock. This will install a program on your device. Run the installed program there and restart the device.
After the device has reconnected to Active Sync, on the PC run the program SDA_ApplicationUnlock.exe in the folder 2 SDA_ApplicationUnlock. It should confirm "succesfully unlocked".
Now the device is ready to receive the "SuperCID" that allows to flash any ROM to it, regardless of Operator or Vendor limitations. To be on the safe side later, please enter on the device *#06# and note down the IMEI that the device reports - you will need it later.
This needs only be done once per device - it is a permanent setting that survives all ROM updates.
Go to the folder 2 prepare for custom flash and
make sure there are no files *.bin left from previous device's activities
then execute Lokiwiz.bat. It will prompt you with 4 options:
Code:
U. Unlock
L. Lock
C. CID Unlock (SuperCID)
Q. Quit
--------------------
Type the letter and press Enter:
Input "C" <enter>.
It will copy a program (itsutils) to the device and it should ask you for permission to execute - grant execution and let the batch file continue. You should find 2 new files beside the Lokiwiz.bat (lock-backup.bin and cid-unlocked.bin). Move them to a safe place immediately and do not repeat the procedure or call another option!
Be careful to label these files unambigously (best is to append the device's IMEI to the name - get it with *#06# before and do not use the IMEI printed on the label of the device - as restoring a wrong *.bin file to a device will kill the GSM radio access (Message: Data Crashes, please contact your... when trying to connect to the network with a SIM card inserted).
Now the device is prepared to receive custom ROMs.
Let's first put the last available Radio ROM and SPL (Secondary Program Loader) to the device. Go to the directory 3 flash latest Radio and SPL and execute ROMUpdateUtility.exe. After successfull update the device will restart in the old OS, nothing has visibly changed - you could still use the device as it is, all your data are still there.
Now the preparations start to erase the old OS and flash the new one.
Deactivate USB connections for the Active Sync
Switch off the device and disconnect from USB
Press Camera Key and keep it pushed down while connecting the USB cable to the PC - wait until the 3-color screen appears and release the camera key.
Start ttermpro.exe in directory 4 format BINFS 1b00000
Select Serial and Port USB
Press <enter> in the terminal window, you should get prompt CMD>
enter info 2 <enter> you should see something like:
Code:
Cmd>info 2
GetDeviceInfo=0x00000002
+ SD Controller init
- SD Controller init
+StorageInit
CMD55 failed
+ SD Controller init
- SD Controller init
+StorageInit
CMD55 failed
HTCSSuperCID ' HTCE
Cmd>
The last line must show HTCSSuperCID ' HTCE.
If you see anything else there (e.g. HTCSVODA0504 㱍dHTCE - which is for an Austrian V1240) the lokiwiz in step 2 above did not work correctly. Still you have not destroyed anything (hopefully) - so to get the old OS start up again, enter ResetDevice <enter> - the device will restart and boot again. Think about what went wrong in the previous steps.
The lokiwiz batch file and the tools behind it are very powerful and can kill the GSM radio access of the device. Be careful with the *.bin files and keep those of different devices clearly apart.
In case you see HTCSSuperCID ' HTCE then you can pass the point of no return (after this the OS and all your data are deleted from the device) and enter at the prompt format BINFS 1b00000 <enter>. (The value 1b00000 depends on the ROM size, so if you use a different ROM, the value may also be different.) After a few seconds the prompt returns and the partition where the OS was stored is cleaned up now. The device will not boot beyond the 3-color screen in this state. You need to flash the new OS in the next step - but before this enter ResetDevice <enter> - the device will restart and return to the 3-color screen.
Terminate the tterm.exe, you will not need it any further.
Re-activate USB connections in Active Sync - you may forget it later.
Enter the directory 5 flash ROM and execute ROMUpdateUtility.exe. The procedure looks the same as in step 3 but takes a little longer. Do not get nervous as the time at 100% extends a few minutes. The device will reboot and bring you to the new OS.
The SD card that shall be used in the device needs to have the NetCF 3.5 files copied to the directory \Windows finally. This is NOT on the device but on the card - you can copy it on the PC while the sd card is in a card-reader or when the device has is mounted, there the path is \Storage Card\Windows
If the device had a SIM-Lock and it rejects your SIM, go to the lokiwiz.bat (again move out all *.bin files) and select "U" for SIM Unlock - again move the bin files in the directory to a safe place (but you should never need them). Mind that the "lock_backup.bin" is just a copy of the current encrypted area in the device. So this file is different after each step you completed before. Worse: if you do not save the FIRST lock-backup.bin you can never go back to this state.
Mind that lokiwiz.bat has worked for me on a Telenor Sim-Locked nordic ROM CID-locked QTEK 8310, so it should work for any other device as well. If you get the dreaded "Data Crashes..." message and your restore of the correct lock-backup.bin did not help either - your last resort is the SIM Unlock service here: http://imei-check.co.uk/c600_unlock.php. It costs you some bucks, but they seem to re-create the encrypted area with the matching IMEI of your device putting it in a SIM-unlocked and CID Unlocked state. Cheaper than buying a new device.
After you have sucessfully flashed your ROM - maybe you try cooking one yourself?
Some updates to the guideline for flashing in the previous and the first post.
be careful with lokiwiz (several hints added)
last resort if you fail to superCID the device: http://imei-check.co.uk/c600_unlock.php
Enjoy - there is no real successor of the Tornado
Thank you for this. I updated my phone because the previous rom was slow and flawed as I discovered. Phone is working great now.

[ROM-Patch] Defyluks: System encryption for the Defy(+) with CM7

Defyluks - System encryption for the Defy(+)​
Warning: This patch is only intended for people who are familiar with Linux and LUKS and know what they are doing. I take no responsibility for any damage whatsoever resulting from using this patch.​
Before applying this patch, I strongly recommend making a full backup of your device. Uninstallation is currently not supported, excepting via flashing back the Stock-ROM via sbf-flash and redoing everything.
Last update: 2012-12-02
== Motivation ==
Until now, there is no working solution for encryption the internal data partition and sdcard of a Defy(+). In theory, Android 3.x+ provides such a possibility, but (afaik) all currently available builds of CM9/CM10/CM10.1 etc. don't implement this feature yet. Apart from that, many users of the Motorola Defy share the opinion that Android 2.3 is more suitable for the device than Android 4.x due to a smaller memory footprint etc. Even in case the standard Android encryption shall become in newer CM releases in the near future, having an alternative for CM7 might be still desirable.
One general problem of the built-in encryption in Android 3.x+ is also the fact that you can't move the data partition on the sd card. In case of hardware damage, you don't have the possibility to pull out your data and send in the device for repairs. Also, you cna't easily mount the data partition from others systems using existing tools like LUKS for Linux or FreeOFTE in Windows.
== Related projects ==
There are a few related projects, but they only work for other devices like the HTC Wildfire or the Nexus One:
LUKS/LuksApp (https://github.com/guardianproject/LUKS)
Luksunlock (https://github.com/guardianproject/luksunlock)
Yaffsunlock (https://github.com/scintill/yaffsunlock)
== What does this patch do? ==
First of all, the patch adds a few new components to CM7:
- the cryptsetup binary (taken from GuardianProject's LUKS porting project)
- kernel modules which provide support for ext4 and jbd2 (taken from Quarx2k's custom kernel for CM10)
- a modified init.rc which is based on the one provided by CM7.2-stable (warning: it replaces the existing one!)
- (temporary) a sample encryption key
After installing this patch, the existing internal data partition in the mtd flash will be ignored during bootup and not mounted anymore! Instead, an encrypted data partion from the sd card will be used.
== Status ==
The patch is currently under heavy development. The current version 0.1 is intended only to give a first preview about this development. Currently, the patch only provides a rudimentary security enhancement in case the hardware breaks, not in case of theft (see the open TODOs below). The performance impact is high for write operations, but negligible for read operations, see the attached benchmark.
== Requirements ==
- Basic knowledge about LUKS
- rooted Defy with CWM and CM7.2-stable
- microSD card in your Defy
== Installation ==
Step 1: Create a key (on your desktop) which will be used for the encryption later on:
dd if=/dev/random of=lukskey bs=1 count=32
Step 2: Mount the sd card externally (via adapter or from CWM) and repartition it. In the following, I assume that the sd card is available as device /dev/sdb. Here is how to repartition it:
/dev/sdb1: the existing FAT32 file system (you can shrink your existing one)
/dev/sdb2: a new partition with fs type (82)
Step 3: Encrypt the second partition of your sd card with the key you created previously:
cryptsetup -c cipher=aes-cbc-plain luksFormat /dev/sdb2 /path/to/lukskey
Step 4: Crypto-mount the partition and create an ext4 fs on it:
cryptsetup --key-file /path/to/lukskey luksOpen /dev/sdb2 encrypteddata
mkfs.ext4 /dev/mapper/encrypteddata
cryptsetup luksClose /dev/mapper/encrapteddata
Step 5: Replace the keyfile in "system/etc/lukskey" in the supplied defyluks.zip archive by your key (that is: unpack the archive, replace the key, pack the archive again)
Step 6: Install the previously packed defyluks.zip archive via CWM on top of CM7.2-stable and boot your device.
== Version history ==
0.1 (02.12.2012): First pre-release
== TODOs (sorted by priority) ==
- cleanly luksClose the mounted data partition in order to prevent data loss
- allow for key entry via some minui (the hardcoded key does not really enhance security greatly. Of course, if someone steals only your sd card but not your phone or if your hardware breaks and you have to send it in it already helps, but apart from that?)
- support loopback-devices on top of the existing vfat filesystem on the sdcard (remove need for repartitioning the card)
- support a more secure cipher like aes-cbc-essiv (the Defy stock kernel lacks support for that, will have to add the proper module)
- make the installation process much easier (i.e. by providing a setup ui like LuksApp does)
- enhance the documentation (provide a real user manual)
- allow for using the internal nand flash (I see some cons here, but okay maybe some people still might want that)
- support other file systems like yaffs2 (does not make sense on sd card, but surely does when using the internal nand flash)
- encrypt the rest of the sd card as well
- support further Defy-ROMs
- replace the precompiled binaries by self-compiled binaries
- replace the current build script (a cruel hack) by a real build system
- support other CM7.2 devices
- make the first bootup faster (currently takes aprox 3 minutes)
Any feedback is warmly welcome!

[Android on Omnia II-GTI8000] - [ROM] - [PORTING] - [FROYO 2.2.2] TWISTER v.2 ROM

Twister Team (Frenkie99999999&Spiderman1961) is glad to present:
​TWISTER 2​
​
Credits to:
almar (Marc)
bsbsbs (Sándor)
Egon
phj (János)
Voyteckst
Frenkie99999999999
kukafei
Linuxsigh
Argentinos
ROM is based on Android 2.2.2 Froyo. I applied code tweaks and improvements to make it more performant and smooth​ROM is free from malfunctions: the system is smooth; any lag will be due only with apps installation not fully compatible or incorrect installation procedure​Android on OMNIAII is a safe bet won thanks to the efforts of many who have worked tirelessly and pure passion: to complain about minor inconveniences is misplaced. You can not expect perfection from our terminal that even natives Android devices have​​
Changelog:
General improvements:
-New Bootanimation by Twister Team​-Trasparent Status Bar​-JelMiBean Theme: new icons, new wallpaper, new buttons, new battery iconsa and so on...​-Locked Launcher in memory by script (disable option in Spicagenmod settings and in launcher settings​-New themed System Apps​-Playstore updated v 4.1.10​-Quick Pick update v. 2.9.4​-AdAway: no ads​-Camcorder shorthcut​-FlashPlayer​-Miui Music Player​-MxPlayer​-Toggle2G to save battery drain​-GApps for CM6 (CarHome, Facebook, Gmail, Latitude, Luoghi, Maps, Navigatore, Genie Widget, GoogleSearch, VoiceSearch, Talk, Twitter)​-Bravia Engine: increased video sharpness​-Xloud Engine: increase loud sound and virtual effects​-New progress bar colour​-Jelly Bean font​-New Kernel: 2.6.32.9 [email protected]​-New Sound system​-New Dialer​-New and hacked MMS.apk: no automatic mms conversion after 4 sms; recipients up 200​
Code improvements and Tweaks:
-Supercharged with adapted zeppellinrox script​-Improved real Mutitasking with "Low Memory killer balanced script": DON'T USE TASK MANAGER TO KILL APP (ONLY IF REALLY NECESSARY)​-Improved automatic detailing databases on boot: better speed and smoothness​-Improved Zipalignin and fixpermission apps on boot: no FC, better battery drain and ram​-Build.prop modified​-Tweak battery for better drain​-Improved VM Tweaks​-Improved read ahead cache up 2048 kb: better speed access data​-Cache flushing on boot​-Better scrolling and touchscreen responsiveness​-Disabled Zram compression: not friendly for our device​-Tweaks for better smoothness​-Network data tweaks for fastest 3G​-Best Dialer responsiveness: fix delays and black screen issue​-Improved photo and video recording​-Kernel tweaks: better I/O and governor settings without random reboot​-Ext4 smart mounting (noatime, disable barrier etc): better speed disk access​-Sysctl tweaks: minor lags​-Automatic screen state scaling​-Better Network Throughput​-GPS issue (only for any users): no thirdy part apps for fix! First fix on my moving car: 3 min. Other fix few seconds​-Video Recording A/V Sync for CM6 removed: crashing video recording​-Both Cameras and VideoCameras working: added VideoCamera shortcut. Use it for videocamera and your apps don't crash​
Credits to:
Moonguy75
Costinuz32
knzo
ImbaWind
zeppellinrox
What's working:​-Audio​-Receiving and making calls​-GPS​-Compass​-Proximity sensor​-Wifi​-Bluetooth​-USB mass storage​-Cameras​Partially working:​-Reset data​​Not working​-Update Binary Superuser​-Theter wifi​
SCREENSHOT PREVIEW​
​DOWNLOAD LINK​
​
​Part 1​Part 2​
After download unzip with 7zip: you will have a folder with all necessary for installation: rom, kernel, haret.exe, startup.txt...​
ROM IS SET ON ITALIAN LANGUAGE: TO CHANGE IT GO TO "IMPOSTAZIONI/LINGUA E TASTIERA" AND CHOOSE YOUR LANGUAGE​
​
Installation instructions
First some considerations:
A. Porting Android on Omnia (born for WinMobile 6.5) is a pure gamble: to complain of minor malfunctions, claiming a perfection that there is not even on the native device is totally out of place.
It's part of game: in almost all cases, these small hitches, which does not at all preclude the daily use of the terminal, are solved with a simple reboot.
B. Please follow the installation procedure to the letter, without neglecting any detail, otherwise block the installation or malfunction with lag and other troubles of the terminal.
C. The installation must be done with telephone SIM and microSD inserted!!!!!
D. It is recommended to install remaining disconnected from the Internet and with the antivirus disabled
INSTALLATION STEPS FOR OMNIAII WITH2GB OF INTERNAL MEMORY​​
LINK TO ILLUSTRATED INSTALLATION GUIDE​​
1. Connect device to PC through USB under WinMobile ("Settings Samsung / Usb Connection / "My Storage")
2. Open MiniToolPartition wizard
3. Delete all partitions in "My Storage".
4. Create three new partitions:
5. FIRST PARTITION: FAT32, LOGICAL, 500mb, label "DISK"
6. SECOND PARTITION: EXT4, LOGICAL, 1250mb, label "disk"
7. THIRD PARTITION: LINUX SWAP, LOGICAL, 200MB, no label
PARTITIONS FOR USERS WITH OMNIA 8GB (Credits to Lagunostrum)​​FIRST PARTITION: 6390 Gb, FAT32, LOGICAL, label "DISK"
SECOND PARTITION: 1250 Mb, EXT4, LOGICAL, label "disk"
THIRD PARTITION: 196 Mb, LINUX SWAP, LOGICAL, no label​
IMPORTANT: For users with Omnia 8Gb, you must change the startup.txt​At line [Set CMDLINE "rootdelay = 2 root = / dev/mmcblk1p2 init = / init"] change as follows:
Set CMDLINE "rootdelay = 2 root = / dev/mmcblk1p6 init = / init"​
DO NOT create Linux partitions SWAP MORE 'BIG 200 Mb,
ACCORDING TO MANY DEVELOPERS, SUCH DIMENSIONS SLOW THE DEVICE​​
8. Close MiniTool Partition Wizard
9. Start Ubuntu in Virtual Machine (those who have not can disconnect the phone from Windows and, after running Ubuntu, can connect with the procedure described below)
10. Click on the menu "Virtual Machine", select "Removable devices", select GTI8000, select "Connect" to connect Omnia to Ubuntu
11. Open "Gparted" or other utility Ubuntu to partition the disk
12. Right-click on "ext4" and "remove" the partition, right-click again to "ext4" and choose "Format as ext4" (with tests carried out, it is more snappy rom installed on a formatted partition from Ubuntu in "ext4 "with respect to a partition" ext4 "formatted by MiniTool)
13. Right-click on "linux-swap" and format as "linux-swap" (for the same reason as above)
14. Close "Gparted"
15. Click on the menu "Virtual machine / Removable devices / Disconnect" to disconnect and reconnect the phone automatically from Ubuntu to Windows (do not disconnect the USB cable!!!!)
16. Close Ubuntu
17. Set the date on the PC on September 2011 (if it does not work in September 2010)
18. Open Image For Windows and choose "Restore (Normal)"
19. Navigate to the folder where you saved the ROM and select it
20. Click "Next" and flag the ROM to be installed
21. Click again on "Next" and choose where to install the ROM: Of course it will be the EXT4 partition (Linux native)("disk"), 1250 Mb created with MiniTool and reformatted under Ubuntu
22. Click "Next" and continue until screen will warn you that all data on the target partition will be deleted and be replaced by those of the ROM: click OK and continue
23. On next screen, leave options settings as you find them
24. On next screen click "Start" and start the procedure.
25. After installation, close Image For Windows and set time PC correctly.
Copy the files "haret.exe", "startup.txt" and "zImage" in DISK. (ie the root of the "My storage" WinMobile).
These files must remain in DISK (ie the root of the "My storage" WinMobile).
26. From WinMobile, with a File Manager, navigate to "haret.exe" and click it to start Android.
27. After first boot of Android, DO NOT USE THE TELEPHONE, wait for SO fully started and RESTART the phone
At the end of the second boot you can enjoy Android on OMNIAII
28. Set Playstore on "do not automatically update applications"!!!!!!!
Choose carefully what to update because recent apps are the most greedy of ram (block the phone) and they bring very little improvement.
ESPECIALLY DO NOT UPDATE GAPPS (CarHome, Facebook, Gmail, Latitude, Places, Maps, Navigation, Genie Widget, GoogleSearch, VoiceSearch, Talk, Twitter), otherwise they will not be opened.WHILE I WRITE I HAVE JUST TESTED FACEBOOK: slow on GALAXY ADVANCE OF MY WIFE, but splinter on my old Omnia
Frequently Asked Question
During installation of our Rom you can present difficulties. Often they are the same and identical are solutions.
For this reason I group here most common issues with most appropriate solutions: all tested and working.
PLEASE READ THESE LINES CAREFULLY BEFORE POST QUESTIONS THAT HAVE ALREADY HERE 'FOUND REPLY
Installation Tweaks​
1. Why 'install in "My Storage"?
'Cause it's 5 times more' fast!
Here's how: Copy files haret.exe, startup.txt and zImage in the Root of My Storage, the 2-Gb or 8 Gb.
2. Can I install in external MicroSD?
Recently many users have done: must comply with these conditions:
-Microsd must be at least class 10
File startup.txt-line [Set CMDLINE "rootdelay = 2 root = / dev/mmcblk1p6 init = / init"] should be changed as follows: Set CMDLINE "rootdelay = 2 root = / dev/mmcblk0p2 init = / init"
-File haret.exe, startup.txt and zImage must be copied on the external MicroSD
3. WinMobile is cleared or noised by Android installation?
Android does not cause, any "noise" to the Windows Mobile operating system installed natively on the phone. It will continue to work regularly: in fact we will have a phone with two operating systems fully functional.
4. What should I do just installed Android?
As soon as the phone has started completely must restart your phone to avoid any problems
5. Why on first boot phone remains locked on Android on Omnia II loading?
Possible answers:
a) Can 'have damaged some files in decompression: REINSTALL ALWAYS REPLACE ON ANY FAILURE
b) There may be some corrupt files in download: trying to re-download rom.
c) There may be a problem on disk address. The kernel has booted, the phone can not find the operating system and crashes.
In this case, proceed as follows:
-write disk address ext4 under Ubuntu ("disk") and change startup.txt (ONLY WITH NOTEPAD + +!!):
for example, if ext4 partition under Ubuntu is dev/sdb6 change the value: root = / dev/mmcblk1p6 init = / init "boot
6. If Ubuntu identifies the ext4 partition (disk) as / dev/sdc6 "(and not / dev/sdb6)" What should I do?
Open the file startup.txt and edit it as the "code" that appears in the format window under ubuntu:
change the last line of the file Startup set CMDLINE "rootdelay = 2 root = / dev/mmcblk1p6 init = / init" boot ----> mmcblk2p6.
7. What is the file startup.txt?
The file contains the parameters address of Android system.
The line we are interested in is the following: "Set CMDLINE" rootdelay = 2 root = / dev/mmcblk1p6 init = / init "
"1" is number disc (if you have inserted a microSD the value must be "1" if it is not inserted must be "0").
"6" is number partition "disk" (in most cases, by partitioning "disk" with MiniTool, is assigned the number 6 to the Linux partition).
If after installation, the phone hangs on Android on Omnia II Loading, 99% one or both of the values mentioned above are incorrect.
In most cases, if you install with microSD inserted, values to be inserted are "mmcblk1p6."
If problems occur the reason is constituted by 'physical address that has been assigned to the partition "disk", in which case we need to understand which the partition number your computer has assigned to "disk". To do this, just to see, when you format under ubuntu, on the top bar of the window formatting: here a code appears "sdbX" where X is the partition number: record it and edit it in the line of reported
8. For other installations have to repartition and format all over again?
No: once done partitioning procedure, next time that you install a future release of the rom, just install the image. TBI, with "ImageForWindows", without touching the partitions.
9. How can I replace the kernel?
Just copy the zImage in "My Storage" and "Storage", and start Android.
10. Why Image for Windows does not work?
You must set date pc on September 2011 (or 2010)
11. To install any update of Rom need to do the whole process all over again or just replace some files?
It should make the whole process all over again.
The kernel can be replaced individually, but the modded if copied at a later time inhibit the free wi-fi. You should clean the cache, delete a file .conf and anyway rom would be unstable.
12. My Omnia 8GB is: how should be large partitions?
Configuration tested and running on Omnia 8Gb (Credits to Lagunostrum):
1) 1st Partition FAT32, 6390 mb, Logical
2) 2nd partition 1250 mb EXT4, Logical
3) 3rd Linux swap partition 196 Logical
13. Can I increase size of Linux swap partition?
Many developers recommend not to exceed a size of 250 MB for partition in question: that instead of increasing the performance to slow down greatly.
14. Why I do not read anymore the external microSD?
For those who have problems with the microSD: Make sure that the SD is working and that is formatted Fat32 Primary and Active. use SDFormatter
15. How can I access the phone as a USB memory?
You have to go in Settings \ Applications \ Development and remove the flag on Debug USB.
16. Why, despite having removed flag on usb debugging phone is not recognized as USB storage?
-First of all, try restarting your computer and phone.
- If this is not enough the solution is the following:
under Windows, you can go to the "Computer Management", then "Disk Management" and there if Android appears without a letter assigned, assign one with the right button, "Change Drive Letter and Paths" and you're done
-Check if you are corrupt drivers of the phone and possibly reinstall
17. Why phone does not wake up after the screen is turned off?
Often it is sufficient to press the awakening and even if the screen does not light up, wait a few more seconds and everything will fall into place.
18. How does hardware buttons work?
HARDWARE KEYS WORKS LIKE ON WINDOWS MOBILE
19. Satellites Fix needs thirdy part application?
No, works perfectly by itself: the first fix is slow (takes several minutes), the following are faster (a few seconds)
20. Why the time is not exact and is always back an hour?
This problem can be solved permanently under WinMobile setting time zone of London / Dublin (with Italian correct time) and under Android time will be ok
21. If one day I do not want more android how do I delete it and only have windows?
Just delete the ext4 partition and expand the fat32 partition to the whole disk.
21. How should I set the Bluetooth?
1) make visible the device
2) under the heading "discoverable duration" set "infinite"
3) under "discoverable timeout" set "2 minute"
4) searches for available devices and match omnia
System tweaks
System tweaks​
1. How can I "paint" notifications pull-down menu in the top bar?
Go to SpicagenMod settingS \ Interface \ Notification colors and choose a color for each entry in the "Statusbar notifications" and "Items notification"; "Notification bar" lets you make additional changes to the bar and colors.
2. How can I save battery power?
-from "System Settings" control which apps consume more battery and block them or set them so they suck less
-Then check with the app CPUSpy if the phone goes into DeepSleep: if there is there any app that runs in the background and consumes. Locate and disable
-use GPS, WiFi and Bluetooth only when needed, otherwise disable
-use 2G instead, switch to 3G only for data connections: it is preinstalled in the ROM Toggle2G that automatically manages the switch (but remember to disable it because otherwise you will not have data connection)
3. How do I see what's running in the background?
Go to Settings, Applications, Manage applications and check what apps are running, for safety always under applications, go to the Services running and check which services are run in the background
4. How can I speed up the execution of the app?
With the pro version of Titanium Pro go to / batch operations / manipulates data / activating "convert DB mode Wal" click it: system is much more responsive.
5. How can I save on the consumption of Ram?
-Not too heavy with both the home, with too many widgets, and the device with too many apps. The phone will have greater reactivity '.
6. How can I make a Nandroid Backup, because here we can not get into Recovery Mode?
With ImageForWindows, you can create a backup image of the Rom, crystallize it with all the settings and installed app. Simply make the backup procedure (full)
7. How to replace bootanimation?
With a file explorer with root access like Root Explorer go to / system / media and replace the bootanimation.zip file.
Or just remove the file, and we'll start the classic writing android that lights up.
9. How do I disable the apps that start up automatically?
Download app from the Play Store that makes access to the list of apps that start automatically on boot.
CAREFUL DO NOT DISABLE APPS SYSTEM, (ie text messages, phone, market, 'Android system, ... otherwise the system becomes unstable!)
System maintenance
SYSTEM MAINTENANCE​
The following commands are all to be understood as to perform on a window Terminal Emulator pre-installed in ROM
To get more in-depth ram in case of remarkable system slowdowns type:
su (enter)
flush (enter)
-To compact database for faster access to the data type:
su (enter)
vac (enter)
-To realign app (especially if you installed new ones) in order to save on battery drain and ram type:
su (enter)
zepalign (enter)
-To Wipe Cache and Dalvik Cache (often used to prevent various malfunctions of the system) type:
su (enter)
sclean (enter)
-To make a Fix permission (needed to resolve issues of app Force Close) enter:
su (enter)
fixfc (enter)
System reboot, after typing these commands, in many cases it will be very, very, very long: do not worry if the bootanimation runs for a long time and the system does not seem to restart.
And 'quite normal. Android is performing the routines start from scratch without reading the previous (now deleted because it caused errors) and eventually will boot more agile than before.
Ubuntu installation method
UBUNTU METHOD​INSTALLATION STEPS FOR OMNIAII WITH 2GB OF INTERNAL MEMORY​LINK TO ILLUSTRATED INSTALLATION GUIDE​
1. 1. Connect device to the PC via USB under WinMobile ("Settings Samsung / Usb Connection / "My Storage")
2. Open MiniToolPartition wizard
3. Delete all partitions in "My Storage" of phone.
4. Create three new partitions
5. FIRST PARTITION: FAT32, LOGICAL, 500mb, label “DISK”
6. SECOND PARTITION: EXT4, LOGICAL, 1250mb, label “disk”
7. THIRD PARTITION: LINUX SWAP, LOGICAL, 200MB, no label
PARTITIONS FOR USERS WITH OMNIA 8GB (Credits to Lagunostrum)​FIRST PARTITION: 6390 Gb, FAT32, LOGICAL, label "DISK"
SECOND PARTITION: 1250 Mb, EXT4, LOGICAL, label "disk"
THIRD PARTITION: 196 Mb, LINUX SWAP, LOGICAL, no label
IMPORTANT: For users with Omnia 8Gb, you must change the startup.txt​At line [Set CMDLINE "rootdelay = 2 root = / dev/mmcblk1p2 init = / init"] change as follows:
Set CMDLINE "rootdelay = 2 root = / dev/mmcblk1p6 init = / init"​DO NOT CREATE LINUX PARTITIONS SWAP MORE 'BIG 200 Mb, ACCORDING TO MANY DEVELOPERS, SUCH DIMENSIONS GREATLY SLOW THE DEVICE​8. Close MiniTool Partition Wizard
9. Open Ubuntu
10. Click on "Virtual Machine", select "Removable devices", select "GTI8000", select "Connect" to connect 1Omnia to Ubuntu: note "DISK" and "disk" that you have created with MiniTool
11. Open “Gparted” or other Ubuntu utility to partition disks
12. Right-click on "ext4" and "remove" partition, right-tap again to "ext4" and choose "Format as ext4" (with tests carried out, it is more snappy rom installed on a formatted partition from Ubuntu in "ext4 "with respect to a partition" ext4 "formatted by MiniTool)
13. Right-click on "linux-swap" and format as "linux-swap" (for same reason as above)
14. Close “Gparted”
15. Open Terminal window:
16. Write following command line: sudo cp /media/DISK/ext4.tar.gz /media/disk/
17. Press enter and wait for operation completion (blinking cursor)
18. Write following command line: cd /media/disk/
19. Press enter
20. Write following command line: sudo tar xzvf ext4.tar.gz -C /media/disk
21. Press enter. Start files decompressing on partition ext4. Wait for operation completion (blinking cursor)
22. Write following command line: sudo rm ext4.tar.gz
23. Press enter.
24. Write following command line: sudo chmod 777 /media/disk/
25. Click on "Virtual machine / Removable devices / Disconnect" to disconnect and reconnect phone automatically from Ubuntu to Windows (do not disconnect USB cable!!!!)
26. Copy files "haret.exe", "startup.txt" and "zImage" in DISK. (ie the root of "Memory personal" WinMobile).
These files MUST remain in DISK (ie the root of the "My Storage" WinMobile). Disconnect device from Pc
27. From WinMobile, with a File Manager, navigate to "haret.exe" and click on it to start Android.
28. After the first launch of Android, DO NOT USE TELEPHONE, wait for the S.O. it is fully started and RESTART phone
At the end of the second boot you can enjoy Android on OMNIAII
Link for download ROM -----------------------------------------------------------------> POST 7​
Ubuntu installation method
DOWNLOAD​​
File ext4.tar.gz​
reserved
Congratulations !!!
Yes, you finally made it. version2 is much better that version 1. almost no bugs. And it is much faster than frenkiedroid. especially your memory performance is excellent. i will install it and try to make it even more faster !!!!
one question. how to activate front camera ? i haven't managed to do it.
spkraul said:
Yes, you finally made it. version2 is much better that version 1. almost no bugs. And it is much faster than frenkiedroid. especially your memory performance is excellent. i will install it and try to make it even more faster !!!!
one question. how to activate front camera ? i haven't managed to do it.
Click to expand...
Click to collapse
Thanks!
It will be appreciated your suggestions about how make it even more faster...
About front camera no news for now: it will be necessary kernel modification...
spiderman1961 said:
Thanks!
It will be appreciated your suggestions about how make it even more faster...
About front camera no news for now: it will be necessary kernel modification...
Click to expand...
Click to collapse
You wrote
"Both Cameras and VideoCameras working"
so i thought you meant back and front camera....
ok my suggestions are
check my ROM's build.prop for code optimizations
also experiment with dalvik cache settings. it can make the ROM a lot faster
remove some services always running (ex is voice dialer that very few people use and makes system slower
remove unnecessary apps (example livewallpapers, geniewidget etc)
you can also set cpu performance settings as default without big loss on battery time, but with big affect on phone's responsiveness
remove some files on the system that make it heavier to load and handle (ex fewer ringtones to choose from ....)
uninstall downloaded apps from manage applications manu, clean /data/dalvik cache using root explorer, reboot system and install downloaded apps again
my recommendation is not to install optional apps on system as many users ignore how to erase them when they do not need them (ex if somebody does not use twitter or facebook doesn't need them
for faster gps i have discovered this solution try it and tell me the results
the biggest improvement you can see is by replacing the phone's framework with miui's one. you can find miui based on CM6. i know it looks a little chindish but very fast. you just port it to our ROM, and since working just keep it's engine (heart) and replace it's apps with the ones we prefer. MIUI gives us the fastest bases on android
to measure if your ROM improvements are working or not use antutu benchmark 2.5 (bugless working on my android 2.2.2), antutu cpu master 2.5.2 and benchmark and tuning from android market
bytheway. with my ROM installed on sd class 10 i got 1035 points on antutu. can you check yours to see if we have a new record and post the result ?
if you think i can help in anything specific just send me a pm or post here. we are all working on the same side to improve our phone
spkraul said:
You wrote "Both Cameras and VideoCameras working"so i thought you meant back and front camera....
Click to expand...
Click to collapse
No both apps cameras: many users denoted issues about one of them
spkraul said:
check my ROM's build.prop for code optimizations
also experiment with dalvik cache settings. it can make the ROM a lot faster
Click to expand...
Click to collapse
These suggestion and other are already inserted
spkraul said:
[*]remove some services always running (ex is voice dialer that very few people use and makes system slower
[*]remove unnecessary apps (example livewallpapers, geniewidget etc)
[*]you can also set cpu performance settings as default without big loss on battery time, but with big affect on phone's responsiveness
[*]remove some files on the system that make it heavier to load and handle (ex fewer ringtones to choose from ....)
Click to expand...
Click to collapse
Many, many users in my country want them and want better battery drain; so if other user want different configuration he can change himself.
They can use Titanium Backup or Link2SD.
However scripts in rom block automatic boot of these apps so they don't affect phone's responsiveness
spkraul said:
[*]uninstall downloaded apps from manage applications manu, clean /data/dalvik cache using root explorer, reboot system and install downloaded apps again
Click to expand...
Click to collapse
With terminal command "su" and "sclean" it's all automatic
spkraul said:
[*]my recommendation is not to install optional apps on system as many users ignore how to erase them when they do not need them (ex if somebody does not use twitter or facebook doesn't need them
Click to expand...
Click to collapse
We can do it
spkraul said:
[*]for faster gps i have discovered this solution try it and tell me the results
Click to expand...
Click to collapse
I read your efforts in many posts: in Twister it is not necessary (at least in my country) any modification for GPS: first fix with moving car about 4-5 minutes, second and other fixes 10 sec maximum
spkraul said:
[*]the biggest improvement you can see is by replacing the phone's framework with miui's one. you can find miui based on CM6. i know it looks a little chindish but very fast. you just port it to our ROM, and since working just keep it's engine (heart) and replace it's apps with the ones we prefer. MIUI gives us the fastest bases on android
Click to expand...
Click to collapse
Ok, can you link me something also in pm?
spkraul said:
[*]to measure if your ROM improvements are working or not use antutu benchmark 2.5 (bugless working on my android 2.2.2), antutu cpu master 2.5.2 and benchmark and tuning from android market
Click to expand...
Click to collapse
spkraul said:
bytheway. with my ROM installed on sd class 10 i got 1035 points on antutu. can you check yours to see if we have a new record and post the result ?
Click to expand...
Click to collapse
I agree with many developers that antutu it is not reliable: however score with antutu is 1033
Little curiosity: are you "argentinos" on modaco?
yes i am modaco's argentinos. i just had chosen different nickname here, but nothing to hide
about antutu maybe it is not the most accurate in the world, but it is one of the very few running on android 2.2. Vellamo, quadrant, geekbench etc demand android 2.3 or better or better gpu. But benchmarks are one of the best tools to measure ROMS speed, compare them and improve them. after all i haven't used cheats to achieve my 1035 score and you also the same for 1033 score. so since we are not cheating antutu it can show us quite reliable results.
About gps. standalone settings are nice for people using GPS very often. for people using it rarely maybe they need to wait 4-5 minutes every time. i had experienced this many times with both wm system and android system and this is why i decided to try and find ms-based settings.
but even with your standalone settings try to change accuracy from 50 to 19 and disable dynamic accuracy (samsung's recommended for i8000 chipset) and i believe you will see improvement on the locking times.
About MIUI based on CM6 download from here
http://www.mediafire.com/download/0q9ljaqmw0lyati/Miui_1.3.18v4_Formel-Cobrato.zip
consult here (but some info on CM7 based MIUI)
http://forum.xda-developers.com/showthread.php?t=1041524
http://forum.samdroid.net/f63/rom-miui-gb-6342/
http://forum.samdroid.net/f62/rom-miui-gb-6349/
p.s. if you have free time please check this thread
http://www.modaco.com/topic/363230-android-rom-needed-for-base/
after cm6 for i8000 will be considered complete and not beta and we are very close to name a version "complete" this can be our next step - project CM7 for i8000. if one person made incomplete CM7 to run on i8000 we can improve it and run better
spkraul said:
yes i am modaco's argentinos. i just had chosen different nickname here, but nothing to hide
about antutu maybe it is not the most accurate in the world, but it is one of the very few running on android 2.2. Vellamo, quadrant, geekbench etc demand android 2.3 or better or better gpu. But benchmarks are one of the best tools to measure ROMS speed, compare them and improve them. after all i haven't used cheats to achieve my 1035 score and you also the same for 1033 score. so since we are not cheating antutu it can show us quite reliable results.
About gps. standalone settings are nice for people using GPS very often. for people using it rarely maybe they need to wait 4-5 minutes every time. i had experienced this many times with both wm system and android system and this is why i decided to try and find ms-based settings.
but even with your standalone settings try to change accuracy from 50 to 19 and disable dynamic accuracy (samsung's recommended for i8000 chipset) and i believe you will see improvement on the locking times.
About MIUI based on CM6 download from here
http://www.mediafire.com/download/0q9ljaqmw0lyati/Miui_1.3.18v4_Formel-Cobrato.zip
consult here (but some info on CM7 based MIUI)
http://forum.xda-developers.com/showthread.php?t=1041524
http://forum.samdroid.net/f63/rom-miui-gb-6342/
http://forum.samdroid.net/f62/rom-miui-gb-6349/
p.s. if you have free time please check this thread
http://www.modaco.com/topic/363230-android-rom-needed-for-base/
after cm6 for i8000 will be considered complete and not beta and we are very close to name a version "complete" this can be our next step - project CM7 for i8000. if one person made incomplete CM7 to run on i8000 we can improve it and run better
Click to expand...
Click to collapse
Thank so much!!!
Very interesting: after my little holidays i will work on these informations and i will answer you. See you soon
Hi, I'm going to try installing this ROM for the Omnia 2. It will be used by my girlfriend so I hope she won't have a hard time using it (I mean bugs or some things not working)
First of all I want to thank you gusy for developing for this phone, it is a good phone but with a wrong OS.
Now I have a couple of questions:
1. There is no other way than to install Ubuntu and using it for the specified steps?
2. Could you please post the exact size of the files inside the 7zip files? I don't want to have any errors during the installation. I have attached a screenshot of the files that I got after I unzipped the 2 7zip files, please check it out and tell me if that's ok.
Thank you again!
sergio_sos said:
Hi, I'm going to try installing this ROM for the Omnia 2. It will be used by my girlfriend so I hope she won't have a hard time using it (I mean bugs or some things not working)
First of all I want to thank you gusy for developing for this phone, it is a good phone but with a wrong OS.
Now I have a couple of questions:
1. There is no other way than to install Ubuntu and using it for the specified steps?
2. Could you please post the exact size of the files inside the 7zip files? I don't want to have any errors during the installation. I have attached a screenshot of the files that I got after I unzipped the 2 7zip files, please check it out and tell me if that's ok.
Thank you again!
Click to expand...
Click to collapse
Hi,
you may not use Ubuntu, but the system would be slower and could create some problems (the ext4 file system created by MiniTool is not exactly the same as the one created by native Linux with Ubuntu).
I suggest, with respect to the guide to make a linux swap partition of 250mb (not 200): it should prevent incidents of freeze.
The size of the downloaded files are correct: good installation.
Enjoy
Hola,
no puede usar Ubuntu, pero el sistema sería más lento y puede crear algunos problemas (el sistema de archivos ext4 creado por MiniTool no es exactamente el mismo que el creado por Linux nativa con Ubuntu).
Sugiero, con respecto a la guía para hacer una partición de intercambio de Linux de 250 MB (no 200): debe evitar incidentes de congelación.
El tamaño de los archivos descargados son correctos: buena instalación.
:good:
spiderman1961 said:
Hi,
you may not use Ubuntu, but the system would be slower and could create some problems (the ext4 file system created by MiniTool is not exactly the same as the one created by native Linux with Ubuntu).
I suggest, with respect to the guide to make a linux swap partition of 250mb (not 200): it should prevent incidents of freeze.
The size of the downloaded files are correct: good installation.
Enjoy
Hola,
no puede usar Ubuntu, pero el sistema sería más lento y puede crear algunos problemas (el sistema de archivos ext4 creado por MiniTool no es exactamente el mismo que el creado por Linux nativa con Ubuntu).
Sugiero, con respecto a la guía para hacer una partición de intercambio de Linux de 250 MB (no 200): debe evitar incidentes de congelación.
El tamaño de los archivos descargados son correctos: buena instalación.
:good:
Click to expand...
Click to collapse
Thank you very much for your response. I will try to install the ROM today (hopefully)
And thank you for the spanish translation. I thought you were from Italy
I am from Argentina.
Saluti!
My phone hangs in "Jumping to Kernel..." what should i do?
eisdrachen said:
My phone hangs in "Jumping to Kernel..." what should i do?
Click to expand...
Click to collapse
Hi,
you posted on 2 thread same question: wich version are you installing?
spiderman1961 said:
Hi,
you posted on 2 thread same question: wich version are you installing?
Click to expand...
Click to collapse
Last time I tried the last Twister on my SGH-i900. Jumping to kernel... On every ROM

[INFO] BOOT PROCESS: ANDROID vs. LINUX

NOTE:
I'm not a developer or Android expert. All information provided here is copied from different internet sources and is to the best of my knowledge. I'll not be responsible for any harm to you or your device resulting from this.
1. PC BOOT PROCESS
Before diving into Android boot process, let's have a look at Linux PC first.
Power Button Pressed
Power On Self Test (POST); identify the devices present and to report any problems
BIOS / UEFI
Necessary hardware initialization (keyboard, disk etc.)
Disk (MBR)
DOS Compatibility Region code (optional)
Bootloader
Active/boot partition (Boot sector)
Kernel
Initrd / initramfs (init)
Services/daemons/processes
BIOS / UEFI is the first software code that is hard-coded on board and runs after we press power button. BIOS runs in real (16 bit) mode of processor, thus it can not address more than 2^20 bytes of RAM i.e. routines can't access more than 1 MiB of RAM, which is a strict limitation and a major inconvenience.
When creating partitions, MBR is saved in LBA0, GPT header in LBA1 and primary GPT in LBA2-33, LBA34 (35th) is the first usable sector. Backup or secondary GPT is saved in last 33 LBAs, last usable sector by OS is ( Total LBAs - 33 ). Partitioning software aligns GPT partitions at larger boundaries, e.g. at LBAs that are multiple of 2,048 to align to 1,048,576 bytes (512 bytes * 2048 = 1 MiB) boundaries. So first sector of first partition is LBA 2048 and so on.
When a system boots, driver of a filesystem is to be loaded in RAM in order to use that filesystem, but driver is itself a file, inside some filesystem. It's like a chicken and egg scenario. So the solution is to always load (as a BIOS/UEFI standard) the first sector on the bootable storage (0/0/1 C/H/S in older schemes and LBA0 in newer), which is (legacy or protective) MBR. This communication between BIOS/UEFI and storage media is through commands which are specific to host controller e.g. ATA commands for devices with SATA/AHCI interface on PC.
Master Boot Record (MBR)
1st 512 bytes (1 sector) at the start of 1st valid disk
Bootstrap code (446 bytes) + Partition Table (64 bytes)
Executable code: Bootloader 1st stage scans partition table and finds 1st sector of active partition (or may point towards intermediate stage)
Partition table provides information about active/bootable partition (and all others as well)
Small size of 64 bytes limits the number of maximum (primary) partitions to 4
Since bootloader unable to understand filesystem (inodes etc.) yet, so MBR is itself executable
Last 2 bytes are boot signatures i.e. to find immediately if disk/drive is bootable or not and hence switch to the next
DOS Compatibility Region
This stage is specific to legacy GRUB, GRUB 2 (default bootloader on most of modern Linux ditros) splits this stage to stage 2 and 3
31.5 KiB / 63 sectors next to MBR, contains filesystem utilities
Still loaded by BIOS routines (or bootloader may use it's own drivers)
Required by certain hardware, or if "/boot" partition (sector containing stage 2) is above 1024 cylinder heads of disk, or if using LBA mode
Volume Boot Record (VBR) / Partition Boot Record (PBR)
Sector no. 63 (64th sector) and above may contain Volume Boot Record or Partition BR, very similar to MBR
Also called Volume Boor Sector, it may be the first boot sector on any partition
NTFS saves VBR as metadata file name $Boot at first clusters, which also contains cluster number of file $MFT. $MFT describes all files on the volume; file names, timestamps, stream names, lists of cluster numbers where data streams reside, indexes, security identifiers (SID's), and file attributes like "read only", "compressed", "encrypted", etc.
If disk isn't partitioned, it's the first boot sector of disk
Boot Partition (if exists)
In MBR scheme, a partition can be marked bootable / active using a flag, usually the first partition of disk
Windows stage 1 bootloader reads and loads only the "Active Partition" from MBR Partition Table
Bootsector or VBR/PBR is read by stage 1 or 1.5 (2 or 3 on GRUB2) bootloader which loads stage 2 (4 on GRUB2) or actual bootloader
MBR / VBR Contains:
Jump instruction (first 3 bytes) i.e. "goto boot code" command
Filesystem header
Executable boot code, usually contains jump instruction for next adjacent sector(s) containing stage 2 bootloader
End of sector (similar to boot signature)
Stage 1 or 1.5 (or 3 on GRUB2) bootloader reads the filesystem table (like MFT / FAT) on partition and loads actual bootloader as a regular file
Bootloader (Actual)
Loaded by previous bootloader from the filesystem of same partition
Loads all necessary filesystem drivers (if any further required)
Configuration is read from database e.g. /boot/grub/ on Linux (GRUB) and <"System Reserved" Partition>/Boot/BCD on Windows (BOOTMGR)
Windows:
BCD is binary file, can be read and modified by commandline tool bcdedit.exe or GUI tool EasyBCD
NTLDR on XP simply used C:\ as active partition reading C:\Boot.ini
Linux:
GRUB makes use of modules to offer extra functionality for complex boot processes
It can show a boot menu to user if needed or configured e.g. for multi-booting or in safe/recovery mode or boot from USB/Network etc.
Locates and loads the kernel of desired OS and ramdisk in RAM
If GRUB is unable to handle the kernel of an OS like Windows, it can be configured for CHAINLOADING i.e. read and execute bootsector of the partition containing Windows bootloader
'os-prober' helps 'grub-install' and 'grub-update' finding Windows boot partition (System Reserved) by reading bootloader configuration in that partition
Kernel
1st MB of kernel from same partition (/boot) loaded in RAM by bootlader in read mode, then switch to protected mode (32-bit) and move 1MB ahead clearing 1st MB
Then swith back to real mode and do same with initrd (if it's separate from kernel)
Kernel contain ramfs drivers to read rootfs from initrd and mount it
Initramfs
Contains minimal filesystem and modules (required drivers which aren't carried by kernel) to access real rootfs (hard driver, NFS etc.)
udev or specific scripts load required modules
<ramdisk>/init is usually a script which loads necessary drivers and mounts real rootfs
finally init switch_root's to real rootfs and executes <real rootfs>/sbin/init; sysV (traditional), upstart (Ubuntu's initiative) or systemD (the latest widely accepted)
init > getty (on virtual terminals) > login (program) > motd > login shell > bashrc / bash_profile​Read more about LINUX CONSOLE & VIRTUAL TERMINALS
UEFI
UEFI can understand filesystem contrary to BIOS, hence no limitation of MBR code (446 bytes)
Needs an EFI System Partition (ESP), preferrably of minimum 550MB
ESP partition is formatted as FAT32 but can understand other filesystems such as FAT12 (floppy), FAT16, ISO9660 (CD/DVD), UDF etc.
EFI firmware reads directly <ESP_Partition>/EFI/<vendor>/<boot_programs> as configured in boot manager (which disk, which partition, which program)
Boot programs make use of EFI firmware or EFI shell or GUI Boot Manager to load kernel
If boot program is just the disk, (no partition and no program configured), then fallback program <disk>/<ESP partition>/BOOT/BOOTX64.EFI is executed
Secure boot feature verifies signature of boot program before loading
Multi-booting is easy, just read different entry from ESP partition unlike relying on single bootloader to chain load all available OS's
EFISTUB feature of Linux kernel allows booting kernel directly as a boot_program
UEFI works better with GPT than MBR
Must read:
ANDROID PARTITIONS & FILESYSTEMS
2. ANDROID BOOT SEQUENCE
There might be a single or multiple bootloaders (to give directions how to boot). For a typical android device (most common Qualcomm SoC / ARM processor), boot sequence is as follows:
BootROM (like BIOS on PC). It's integrated with SoC.
Processors, bootloaders
POST
SBL
Parallel loading related stuff from different partitions.
Application BootLoader (aboot)
Primary Boot Mode (if no Kernel detected or if bootloader/download mode key combination applied)
Bootloader/Download Mode
Secondary boot
Kernel (hardware detection and populating /sys, /dev/ and /proc directories as the processes start) and initramfs (creating rootfs and other pseudo filesystems on rootfs)
Init (first process with PID "1". It initiates further loading of processes and daemons)
System / OS (ROM)
Recovery (if recovery mode key combination applied. It's a kernel with UI to perform basic troubleshooting operations)
3. BOOTLOADERS
Bootloader(s) facilitate the the initial starting up of device by taking control from SoC, performing necessary checks, loading required components and then hand over the charge of booting to kernel. RAM is detected at first stage to start loading configuration of other hardware (like keypad, display etc.) in it.
There exist(ed) multiple bootloaders which are executed by different processors, on different devices with different (partition) names like RPM (PBL), DBL (Device Boot Loader; CFG_DATA or sbl1), SBL2, SBL3 (QCSBL) and OSBL (Operating System Boot Loader) etc.
In a nutshell, on modern ARM devices (Qualcomm SoC):
BootROM / iROM and PBL
iROM run by CPU0 on power button press, loaded in iRAM (before RAM is initialized)
It may set up RAM and execute PBL in RAM or leave this for SBL. iROM/PBL is hard-coded on SoC, written during CPU production process and it's closed source.
On devices (such as open boards or some tablets) which support booting from multiple sources like eMMC/sdcard/USB/UART/Network like a PC BIOS, there is an extra stage between iROM and PBL:
IBL (Initial BL)
It's also loaded in iRAM. Depending on CPU pin settings (hidden and soldered or exposed for manual switching) informed by iROM, IBL passes boot mode selection to PBL and optionally checks PBL integrity if itself e-signed by iROM.
SBL or XBL (Preloader)
IBL calls SBL from eMMC/SDCard which supports LCD output. SBL initializes the DDR RAM, loads the trusted firmware (TZ) and the RPM firmware if not loaded by BootROM. SBL calls the final bootloader after self testing the device.
Uboot is open-source secondary bootloader for embedded devices. However sources of SBL can also be obtained from Qualcomm.
ABOOT (APPSBL; predecessor of Little Kernel)
ABOOT loads Partition Table, kernel, splash screen (logo) and modem. It's also responsible for charging mode and fastboot mode. Memory addresses in RAM for boot/recovery partitions are hard-coded in aboot.
Other examples of final (i.e. just before kernel) bootloaders are uboot (traditional Linux bootloader for embedded devices) or manufacturers' developed BL's like hboot (used by HTC) and redboot etc.
Manufacturers put their limitations (say of network carrier i.e. SIM lock and others) at this stage. USB protocol isn't enough and communication with bootloader to hack such restrictions require special devices (called Flashing Box or Service Box in common language), even sometimes a protocol like JTAG i.e. talk directly to microprocessor.
As a norm, all of these stage-1,2,3... bootloaders are simply called BOOTLOADER. While on some devices there is no bootloader partition at all and bootloader(s) resides on SoC.
Coming back to the booting process, after initializing boot process, bootloader (if it's locked) checks the integrity of boot.img (normal boot) or recovery.img (recovery boot), loads them in RAM and transfers control to kernel offering it with "phys_initrd_start" address of compressed (cpio, gzipped) initramfs.
4. KERNEL & INITRAMFS
Once the kernel is loaded and extracted in RAM by bootloader along with parameters, kernel starts executing. Kernel is in fact a self-contained (static) executable binary, made up of many object files (.o) linked together at compile time. Once the architecture and CPU are identified, architecture-dependent code is executed as per parameters passed from bootloader. Then arch-independent stage is executed which includes setting up drivers (display, touch etc.), filesystems like rootfs, tmpfs, proc, ext4 etc. and initializing console as well (if configured). Here the kernel-space ends and user-space begins (what they call it).
Kernel extracts compressed initramfs in rootfs (which itself is ramfs or tmpfs) and executes /init binary which subsequently reads its configuration files /init.rc and other /*.rc files written in Android specific init language. With the help of kernel, init mounts pseudo filesystems /sys and /proc and populates /dev directory containing device node files. Then it mounts /system and all other partitions including /data (also decrypts it if encrypted) and sets (SELinux security) policies, system properties and environment variables (PATH, EXTERNAL_STORAGE etc.). Additionally init also look after any hardware changes (ueventd) and started services changes (watchdog) occurring dynamically.
Finally init starts the runtime located on the system partition. One of the major last processes started by init is Zygote (Java virtual machine) which compiles apps to run for specific architecture (mostly arm / arm64).
DEVICE TREE BLOB
Device Tree Blob (DTB) - created by DT Compiler (DTC) from DT Source (DTS) text - is a mapping of hardware components on a board/SoC and usually a part of kernel source.
PC hardware usually support hardware enumeration through ACPI i.e. kernel may enquire (probe) the buses - PCI (internal devices), USB (external devices), SCSI (storage devices), HDMI/DVI/VGA (display devices) etc. - which device is connected to it.
Buses on embedded devices (including Android devices) mostly don't support enumeration (hardware discovery) because there are usually fixed set of devices and no option for a different OS to be loaded on device. Therefore OS needs to be informed of all connected devices and this is done by providing a standard DTB to kernel. DTB is provided by SoC / motherboard vendor and is usually a part of kernel source. During boot process, DTB is loaded by bootloader at boot time and passed to kernel so that it can discover hardware and create node points accordingly.
We can view device tree on Adroid device by:
Code:
~# ls /sys/firmware/devicetree/base
~# ls /proc/device-tree
DTB may live on a separate dtb/odm partition as specified by AOSP (and was the proposed solution for ARM based embedded Linux devices before Android's birth) but that isn't widely practiced. Usually DTB is appended to kernel zImage/Image.gz or placed at second stage inside boot.img.
VERIFIED / SECURE BOOT
Ensuring a chain of trust from Power ON up to loading of kernel is with the domain of SoC vendor (Qualcomm, Intel etc.) and OEM's. Injecting some malicious or harmful code at any point during booting is made harder to the extent of impossibility.
To ensure a secure booting chain, PBL verifies authenticity of SBL which subsequently verifies integrity of bootloaders (TZ, RPM, DSP, HYP and aboot) so that to avoid loading of unsigned images (boot, recovery, system and others). TZ, after being loaded by SBL also verifies ABOOT using a hardware-based root certificate.
A bootloader with Verified/Secure Boot implementation verifies boot.img or recovery.img (kernel, initramfs and DTB appended to kernel or on second stage of boot.img) by matching their signature with key(s) stored in "OEM keystore" (some partition like CMNLIB, KEYMASTER or with some other name) which itself is signed by OEM. Some vendors allow replacing/appending this keystore with custom one so that custom signed images can be flashed followed by re-locking of bootloader. A simple detail is given here.
At this stage, the chain of trust is handed over to "dm-verity" key stored in boot image initramfs, responsible for "Verified Boot" process of Google/AOSP. Dm-verity (a part of Verified Boot implementing Linux Device Mapper by Google) is a kernel feature i.e. it comes into action after boot image (kernel and ramdisk) is loaded in RAM. It verifies subsequently loading block devices; /system, (/vendor if it exists) and optionally others.
For details see this, this and this.
Google suggests integrating libavb (native code to verify integrity of boot.img) in bootloaders starting from Verified Boot 2.
Unlocking Bootloader
Read here to know about the risks of BL unlocking.
Unsigned kernel or recovery cannot be loaded unless bootloader is unlocked. To make any modification to OS, a critical piece of process is disabling a security system built into the Android's bootloader (aboot) that protects the read-only partitions from accidental (or intentional) modification for privacy, security and DRM. This is what's referred to as "unlocking NAND" or "unlocking bootloader." You have to firstly unlock bootloader to modify partitions "boot" or "recovery" and to gain root access on /system. If bootloader is locked, you only have write access to /cache and /data partitions. Everything else is read-only on device and bootloader will prevent unsigned images from being flashed to the phone. Unlocked bootloader ignores signature verification check which was initiated by BootROM and then transferred to "SBL" and then to "ABOOT" while loading kernel or recovery.
Some newer devices don't allow unlocking of bootloader directly (FRP) without permission from manufacturer to ensure more security i.e. contents of partition "devinfo" are signed by the OEM and can't be modified without their approval. After having permission, an official method is provided to unlock BL using PC. Still some functions related to Proprietary Content might be lost due to bootloader unlocking.
DRM is used to protect content from being copied.
Certain pre-loaded content on your device may also be inaccessible due to the removal of DRM security keys.
Click to expand...
Click to collapse
Android Rooting
Must Read: Root User and Linux Capabilities: Linux vs. Android
Note: Unlocking Bootloader and Rooting breaks "Verified Boot". It can be dangerous.
In order to perform some privileged task on Android, we need to "root" the device first. Since it's impossible to start a process with elevated privelages from within running Android OS, rooting usually involves running a root process (su-daemon) from boot with all capabilities. Superuser requests are made by any non-privelaged programs by executing "su" binary and permissions are managed by an app.
In early days, rooting usually involved booting into a custom recovery which in turn mounted and modified /system files. Usually some daemon's executable binary was replaced with a custom script. In order to address the OTA and other issues caused by improving security features (SELinux, Verfied Boot, SafetyNet etc.), systemless root method was introduced which is used by latest apps like Magisk. It involves modifying /boot image and putting some files on /data as well. So a new init service is injected fulfilling all necessary requirements of new security mechanisms.
In both cases, a locked bootloader won't boot custom recovery or modifed kernel (boot.img). See Verified Boot. Therefore bootloader needs to be unlocked for rooting.
However it is possible to gain root sometimes without unlocked bootloader but not always.
Other methods of rooting a phone from within a running ROM using some sort of One-Click rooting solution (KingRoot, Z4Root, KingoRoot etc.) depend on some vulnerability or exploit in Android OS. Making such security breaches is getting harder and harder with every new release of Android and with improved defense mechanisms, though it varies for different vendors too. The most prominent was with the release of Lollipop and Marshmallow when systemless method had to be introduced beacuse the previous methods failed to work. When phone is rooted using one of such improper root methods, there is a high probability to face "incomplete root" like messages at some point. If such a rooting method works for your device, it's alarming. This exploit is also a way for malware to enter your device. For examples, see Magisk Installation - Exploits, this and this. A very popular exploit dirty cow was patched later.
In addition to that, there are some hacks for certain devices to flash custom recovery without unlocking bootloader using some kind of Firmware Flasher tool (SPFlasher, MiFlasher etc.) in Download Mode because Download Mode provides access to device even before bootloader/fastboot is loaded. Or if you are expert in coding, you can mimic the custom recovery image look like the factory signed firmware and flash it through stock recovery. But this exploit isn't a universal solution either.
So the proper way to rooting which doesn't need any vulnerability, goes through unlocked bootloader. While buying a new phone this must be considered. Keeping you away from root access and unlocked bootloader goes in favor of vendors. By forcing you to use their ROMs (with bundle of useless bloatware apps), they earn a lot from you - money as well as forced loyalty - by collecting data, showing ads and using a lot of other tactics. Go for a brand that provides kernel source and ability to unlock bootloader (on customer's responsibility and with voided warranty obviously).
FIRMWARE UPDATE PROTOCOLS (BOOTLOADER MODE)
Likewise BL, on every device there might be a single or multiple BL modes with different names like bootloader mode, download mode, emergency mode (EDL), ODIN (Samsung), nvFlash tool etc. When we boot in BL mode, device is stuck on boot logo. Some factory flashers work in these modes such as MiFlasher (Xiaomi) and SP Flash Tool (for MTK devices). Bootloader or Download Mode is accessible even if device is soft bricked i.e. if Recovery and/or ROM isn't accessible.
Download Mode
Download Mode (certain button combination while powering on device; usually Vol. Up + Vol. Down or Vol. Down for longer duration + Power) is an official method used by many vendors to flash factory firmware / updates using Flasher (software). Emergency Download Mode (EDL), as it's called on Xiaomi Devices, can also be accessed through fastboot/adb commands or by using some jigs/jumpers. However, to ensure more security, EDL is disabled on some newer devices.
Download Mode is primary to bootloader mode (at PBL or SBL stage) and can be used without unlocking bootloader.
Odin (Samsung), QPST/QFIL work in Download mode (Qualcomm HS-USB QDloader 9008).
When we boot in Download mode, device is stuck on blank screen.
Fastboot Mode
Fastboot - provided by ABOOT - is a software development tool and a standard communication protocol for Android bootloader. It's an alternate of recovery flashing that works in BootLoader mode (aboot) and comes bundled on most of the recent ARM Qualcomm devices. It's a minimal UI through commandline to interact with device in case of failure or to modify / flash partitions. Some OEM's provide fastboot with limited functionality e.g. 'fastboot oem' commands not working and some devices haven't at all. It's up to the discretion of mobile phone vendor.
Fastboot mode is used to perform operations through commands when device is connected to PC through USB. It works even when phone is not switched on in Recovery or ROM or even if android isn't installed on phone. You can read here what operations we can perform through fastboot mode.
Only NAND (eMMC) and USB modules (drivers) are activated at this stage.
INIT PROCESSES & SERVICES: ANDROID vs. LINUX
FILESYSTEM TREE MOUNTED BY INIT: ANDROID vs. LINUX
RESOURCES:
From the bootloader to the kernel
RESERVED
RESERVED
RESERVED
RESERVED
You have to firstly unlock bootloader to modify partitions "boot" or "recovery" and to gain root access on /system. If bootloader is locked, you only have write access to /cache and /data partitions. Everything else is read-only on device and bootloader will prevent unsigned images from being flashed to the phone.
Click to expand...
Click to collapse
I'm under the impression that unlocking the bootloader is not mandatory for rooting the device.
You can root the device with a locked bootloader and gain full access to /system partition.
NikosD said:
I'm under the impression that unlocking the bootloader is not mandatory for rooting the device.
You can root the device with a locked bootloader and gain full access to /system partition.
Click to expand...
Click to collapse
Yeah I think my brief statement is a bit misleading because rooting is out of the scope of this thread. I have added some details to first post.
Thank you very much for all this useful info.
Some more comments.
A locked bootloader won't boot custom recovery or modified kernel (boot.img)
Click to expand...
Click to collapse
It happens to have a budget Chinese tablet with Oreo 8.0 and MediaTek SoC, which I can root using a modified/patched boot.img with Magisk v17.1 inside of course - I mean full root without problems - keeping the bootloader locked before and after rooting.
In addition to that, there are some hacks for certain devices to flash custom recovery without unlocking bootloader using some kind of Firmware Flasher tool (SPFlasher, MiFlasher etc.) in Download Mode because Download Mode provides access to device even before bootloader/fastboot is loaded
Click to expand...
Click to collapse
The tablet mentioned above, belongs to this category too.
Using SPFT (Smart Phone Flash Tool), I can flash custom recovery TWRP for my device without unlocking the bootloader.
So, I have two questions:
1) Is it rare to have such a device or is it common nowadays to be able to root and flash custom recovery TWRP with locked bootloader ?
2) How is technically possible to patch boot.img for rooting and flash TWRP using SPFlashTool (even in download mode before bootloader) without complains afterwards from bootloader, verified boot, dm-verity and all these safety checks that validate digital signature of Vendor ?
I mean you can do whatever you want before bootloader starts, but how can you escape from security traps after the initialization of bootloader verifications ?
Thank you.
NikosD said:
1) Is it rare to have such a device or is it common nowadays to be able to root and flash custom recovery TWRP with locked bootloader ?
Click to expand...
Click to collapse
I'm not sure how common it is but I must say these are exploits. Developers are making use of these vulnerabilities for positive and negative purposes. But these are not a "long-term" solution for rooting.
2) How is technically possible to patch boot.img for rooting and flash TWRP using SPFlashTool (even in download mode before bootloader) without complains afterwards from bootloader, verified boot, dm-verity and all these safety checks that validate digital signature of Vendor ?
I mean you can do whatever you want before bootloader starts, but how can you escape from security traps after the initialization of bootloader verifications ?
Click to expand...
Click to collapse
That's what my point is. Fastboot code verifies signatures/hashes only when flashing the image and doesn't verify or fails to verify integrity if image is already flashed. This is not the desired behavior so it's an exploit and it should be closed. Letting unsigned images be flashed in Download Mode is another exploit which is common with Chinese vendors as far as I have come across some instances. They don't address "loopholes" seriously. Failure to stop security breaches at or after bootloader level is definitely on SoC Vendor or OEM's part. I have added a paragraph in first post with some useful details and links.
This link explains:
The Qualcomm SoC is analyzed in the previous chapter dload / edl mode, the mode in the firmware image download process does not do any verification, can be directly written into the brush.
Click to expand...
Click to collapse
It's badly translated from Chinese but is informative.
Exploiting Qualcomm EDL Programmers is a complete series on this subject summarized here.
mirfatif said:
Only NAND (eMMC) and USB modules (drivers) are activated at this stage.
Click to expand...
Click to collapse
Hey pal, I'd like to know if you could help me with an issue I'm facing. I have a Moto G5 that isn't booting to any ROM (it either bootloops in bootlogo or in boot animation), and also on TWRP and during the boot animations the device is slow as hell (like 0.5 FPS on TWRP and even less on boot animation; on TWRP the device also takes a few seconds to complete even the simplest tasks - like the press of a button or the swipe of a slider - here's a video that shows differences between how stuff works on fastboot and how slow things are on TWRP, it takes like 2 hours to completely flash a custom ROM, i.e.).
I know much of the issue will be device-specific, but my point (and the reason I quoted that specific part of your OP) is that, on fastboot mode, the device is snappy and responsive. When I press a button it completes the corresponding task immediately, frames don't stutter (not that there are any animations to be rendered in fastboot, but when I switch from one option to another using the volume keys, it does so on screen as it should, with no lag), and so on. Stock recovery also seems to be ok with speed, but it's even harder to measure than fastboot because, in almost 10 years meddling with android devices, I have always found stock recoveries (and CWM in the pre-TWRP times) to be somewhat slow. Stock recovery definitely looks snappier than TWRP, though. Tried several ROMs, both custom and stock, and the issues remain on all of them.
I got to this post by researching if fastboot mode was stored on the same NAND chip as recovery, OS and so on (found out that yes, it's all on the same chip). If it wasn't, I could just assume it was a hardware fault on the NAND chip, and that would be the reason that fastboot was running fine but recovery and OS weren't, but since they're all on the same cell, I can only think that some part of the system (I mean as in every single code that runs on the device, not only the OS) that loads on TWRP and on normal boot, but not on fastboot (and possibly not on stock recovery) are faulty, thus being a software issue (either solvable with just a normal USB cable or needing a flash box).
So, my question is: which are the differences in the parts of system loaded by fastboot and by TWRP? Are there any parts that are loaded by TWRP that aren't loaded by the stock recoveries on most devices?
I know it's a rather complicated question and some stuff might be device-specific, but if there is anything you could tell me that are more generic to every Android device, it would help me a lot. Thanks in advance.

Categories

Resources