Related
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.
NOTE: full jtag instructions to unbrick or root devices can be found on the cyanogen mod wiki:
http://wiki.cyanogenmod.com/index.php/JTAG_DREAM_AND_MAGIC
----
Any G1 user disappointing believing they are unable to use the latest buggy 1.5 cupcake android release from rogers.. look no further.
With a 2005 series SPL all you need to do to successfully use this spectacular firmware on your phone is:
1) extract the rom.nbh form the windows installer;
2) enter fastboot mode on your phone and run "fastboot flash nbh rom.nbh"
This flashes the Official Rogers firmware on your phone in all its glory; including:
1) bad battery life
2) internet that drops periodically even in strong signal.
3) old version of android (1.5)
4) no apps2sd
http://twitpic.com/19p2wm - Home Screen
http://twitpic.com/19p355 - Rogers boot logo
http://twitpic.com/19p397 - About Screen
http://twitpic.com/19p3bm - SPL (close)
http://twitpic.com/19p3gk - SPL (again)
-----
So now you are asking ... why did I do this.. mostly because (as the wires show) The phone is already jtaged And I intend to use it to show how to remove the firmware via jtag. (hopefully tomorrows posting)
However its interesting to note the T-Moblie G1 *CAN* run the EBI1 radio 3.22.26.17 with related EBI1 port and SPL. (I do recommend that if you care to test EBI1 ports on a G1 ... make it a rooted rom not the rogers one)
----
Edit: Brick->Alive .. Rogers->custom a A phone's journey is posted..
While many technical details are provided this is *not* intended as a solution for all. as it requires some skill and equipment to utilize jtag. openocd is used for its relative cheapness and open source nature. Other products will likely work just as well but may need some minor process changes.
How to remove the post 911 firmware via jtag right?
(ROM version 1.89.631.1 Rogers)
Newbies please do not threadcrap this asking for unbrick for your G1 yet. As of right now this method is still not just for everyone.
Original JTAG thread for more info: http://forum.xda-developers.com/showthread.php?t=591048
xaueious said:
(ROM version 1.89.631.1 Rogers)
Click to expand...
Click to collapse
That is what the phone says it is on the about screen (not surprised I did flash the full nbh)
I was asking because you didn't mention which one you were talking about. There was also that old pre 911 nbh, ROM version 1.85.631.5 for Rogers. This rom worked with flashrec (one-click root).
I still know very little about JTAG but I thought I might as well post some of the SPL/radio combinations here with some links.
A link to the old Rogers ROM is here for future reference for any Rogers Dream users to return to a rootable stock image for some reason: http://forum.xda-developers.com/showthread.php?t=625073
Contains stock pre-911 update Rogers ROM with
HBOOT Version 1.33.0009
Radio Version 3.22.20.17
* * * Reference Recommended SPL + Radio Combinations * * *
Anyhow if everything works... Useful links for SPL, radio and recovery flashing:
Rogers Dream Info for Reference, no Rogers Waiver Signed
Upgrade to 3.22.26.17 if you haven't signed the waiver or don't want to. This makes your phone incompatible to most ROMs in this thread until you flash a 'kernel port' update file.
Needs Amon_RA G1/Dream recovery version R
So target would be:
HBOOT VERSION: 1.33.2005
RADIO VERSION: 3.22.26.17
Rogers Dream Info for Reference, Rogers Waiver Signed OR T-Mobile G1
This radio makes the phone work with most G1 ROMs you can find on these forums.
Needs Amon_RA non-R G1/Dream recovery or Cyanogen's G1/Dream recovery
HBOOT VERSION: 1.33.2005
RADIO VERSION: 2.22.23.02
* * * Download Links for Relevant Files * * *
Amon_RA Recovery for G1/Dream
http://forum.xda-developers.com/showthread.php?t=566669
Radio 2.22.23.02
T-Mobile G1 radio. EBI0 kernel. Makes the G1/Dream compatible with most ROMs posted in this forum.
http://forum.xda-developers.com/showpost.php?p=5763943&postcount=1
Radio 3.22.26.17
T-Mobile G1 radio. EBI1 kernel (aka Magic 32A old radio kernel). Makes the G1/Dream incompatible with most ROMs posted in this forum until you flash an additional kernel (kernel port). Allows for flashing of Magic old radio ROMs if ROM is not too large for the G1/Dream's internal flash memory.
http://wiki.cyanogenmod.com/index.php/Upgrade_Rogers_Dream_Radio#Preparations
SPL/HBOOT 1.33.2005
Also Danger/Death SPL. Originally for Sapphire/Magic but has support for Dream to increase size of /system partition. Prerequisite for some ROMs.
http://sapphire-port-dream.googlecode.com/files/spl-signed.zip
Or here:
http://wiki.cyanogenmod.com/index.php/Upgrade_Rogers_Dream_Radio#Preparations
xaueious said:
I was asking because you didn't mentioned which one you were talking about. There's also that old pre 911 nbh aka ROM 1.85.631.5 Rogers.
Now this ROM might be good for your procedure for Rogers Dream users. It's here by the way in case you didn't have a link: http://forum.xda-developers.com/showthread.php?t=625073
Click to expand...
Click to collapse
Yes, that should be just as good (and you will have a way to root without jtag just in case ). I believe that it is the exact same SPL and slightly different radio (might matter for jtag though). The only reason we were able to root this rom was because of the kernel exploit.
A phones Journey
So a short recap for those not following along in the various threads.
The T-Mobile Phone in question
I've recently (off ebay) got a bricked HTC T-Mobile G1. (failed attempt to install the 2005 SPL.. (**sidenote)
Given it was a cheap phone it was a good candidate for jtag testing; after shorting something out on previous jtag work on my rogers dream. (the jtag port is the same on both phones.. and it did work on the dream for a bunch of tests before the incident)
Details of the de-brick are on this threadRogers Rom
Given the phone already has jtag attached (a little bit of a painful process) I decided to try unrooting a rogers rom on it before going to any other phone. So I took the nbh from the rogers installer (I still have the original 1.89.631.1 rom.nbh from when I created the hacked version which skipped the spl/splash1 portions of the flash.)
This flashed from the 2005 SPL without incident making the T-Mobile phone running a full rogers stack (splash image included) see op post for images of the phone/rom in this mode.Unroot (I know this is what you are here for)
(Note an updated version of this process now exists on a wiki: http://wiki.cyanogenmod.com/index.php/JTAG_DREAM_AND_MAGIC )
So now with a fully locked SPL in place and jtag already set up time to hack out of the rogers rom to an EBI1 port!!
Prerequisites:
A) phone running locked roger rom 1.89.631.1 (actually as listed it will work for any rom on radio 3.22.26.17 and with offsets in my de-brick post other radios.
B) Jtag adapter.. I'm using OLIMEX ARM-USB-OCD.. however others will work as well.. my steps assume the openocd program on your computer which supports many USB/ParPort adapters. (my current cfg hopefully will improve but works for this hack.. note its for version "Open On-Chip Debugger 0.4.0" not the old cvs/svn version that is on the CD with the hardware)
C) outfit phone with jtag adapter.. this i will leave to another topic.. see the Jtag thread for the test points.
D) A HTC Serial wire.. I recommend without the +5 power line since blue light mode is sometimes hard to enter while the device is charging.. (information on my wire with links to parts. If you wish you can also attatch a USB wire to the USB leads which allows you to see serial output while flashing.. but ensure you can have the USB unplugged while the oemspl serial is in use.
E) 2005 SPL *.img file extract it from the zip file: http://sapphire-port-dream.googlecode.com/files/spl-signed.zip
MD5 (hboot.img) = cdf75d34e24937da1a8a84bcd72496c3
F) Recovery *.img .. your favorite flavor of '-R' version from this thread: http://forum.xda-developers.com/showthread.php?t=566669
G) a sense of adventure
Procedure:
1) Ensure the jtag adapter is hooked up to the phone
2) power on phone into blue light mode
3) attach serial wire
4) connect to serial console (mtty in windows, "screen /dev/<serial device> 115200" in osx/linux)
5) start openocd or other jtag application (openocd -f dream.cfg)
6) start telnet to the ocd: "telnet localhost 4444"
7) run the following:
Code:
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> [color=blue]halt[/color]
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x200000d3 pc: 0x0090861c
MMU: disabled, D-Cache: disabled, I-Cache: disabled
> [color=blue]mww 0x0090379C 0xea000013[/color]
> [color=blue]mww 0x9029d8 0x0[/color]
> [color=blue]load_image [b]<pathto>[/b]/hboot.img 0x0[/color]
No working memory available. Specify -work-area-phys to target.
no working area available, falling back to memory writes
524288 bytes written at address 0x00000000
downloaded 524288 bytes in 11.635834s (44.002 kb/s)
> [color=blue]mww 0x00000c0c 0x98000C4C[/color]
> [color=blue]mww 0x00000c08 0x98000C4C[/color]
> [color=blue]mww 0x00000c04 0x98000C4C[/color]
> [color=blue]mww 0x00000c00 0x98000C4C[/color]
> [color=blue]resume[/color]
The offsets are based off my de-brick post
* 0x0090379C is the CID bypass point for 3.22.26.17
* 0x009029d8 is 4 less than the previously defined breakpoint for 3.22.26.17 SPL modification (for other radios subtract 4 from my breakpoint location);
This is the location of a subroutine call to load the SPL.. since we are going to load it our self we want to nop the instruction.. no 0x0 is not the nop instruction.. but it will achieve the same results (and lack their of).
* load_image will load a file into the phones ram; point this at the hboot.img you downloaded as that is what we want to run
* 0x00000c00 to 0x00000c0c is the switch jump table in the 2005 hboot image once loaded for the boot mode.. we are forcing modes 0-3 to ruu/fastboot mode.
* then we can resume the CPU and optionally kill openocd.
8) into the serial termal run command "?" this ought to now output help on many commands (before it would only say invalid command)
9) run command "cego"
<phone will now boot into the ram image of 2005 SPL; display splash image (if screen is connected) and enter fastboot mode>
10) remove serial wire and attach USB wire.. or plug in usb part of USB/serial hybrid wire.
12) "fastboot flash hboot hboot.img"
13) "fastboot flash recovery recovery.img" (the ebi1 RA recovery)
14) "fastboot oem powerdown"
Now you can boot into recovery and flash your favorite EBI1 rom.. or if you don't like EBI1.. follow the EBI0 installation instructions
** sidenote: To packagers and those making processes.. Given all I have seen to date.. whenever possible flash radios and SPLs via fastboot not recovory zip files..
If you are stuck on a splash screen on boot.. both the SPL and radio are working.. they are just usually stuck in an invalid mode.. which is less likely to happen if flashed by fastboot.. this particularly applies where the 2005 SPL is involved.
Hacking can be fun.. but this hacking is not cheap
If interested donations are accepted
I wonder why no one's responding to this thread. This is great news!
I agree that this is good news. Just bought a slightly used Dream and it was. Just my luck that the previous owner ran the mandatory update shortly before selling it.
I am a little unsure about the process though. Does the jtag involve physically modifying the phone? If so, is there any chance that this method will lead to a non-jtag way of getting around the perfect SPL?
SilentTweak said:
I wonder why no one's responding to this thread.
Click to expand...
Click to collapse
Because most of newbies here doesn't have idea about what is talking ezterry with his method
I might be motivated to try this if I actually had a brick. If I buy a Dream I might look into this.
For now I am not motivated to get my own jtag working. ezterry and other fellow xdaers on the other thread seem to be trying to find a method that doesn't require soldering.
Dreaming
I would be willing to try this on the $100 Dream i picked up, but the only thing is spending another $50-$100 on JTAG and serial cable equipment. which i might F#@CK the phone LOL
PS is it possible to use a cheap parallel port jtag to do this?, i think diffrent software would be required for the process though....any suggestions?
Thanks
Raymar23
raymar23 said:
I would be willing to try this on the $100 Dream i picked up, but the only thing is spending another $50-$100 on JTAG and serial cable equipment. which i might F#@CK the phone LOL
PS is it possible to use a cheap parallel port jtag to do this?, i think diffrent software would be required for the process though....any suggestions?
Thanks
Raymar23
Click to expand...
Click to collapse
No reason a parport adapter won't work, and openocd supports many part port adapters.
Also if you are more comfortable with other arm compatable software it ought to be easy to port the steps.. its just ram writes.
I just don't own any computers I can plug in Part port devices anymore.
scholbert from the other jtag thread may be able to give more info.
http://www.diygadget.com/universal-jtag-adapter-for-routers-modem-fta-and-more.html
Could I use this JTAG adapter? Or is there another adapter on this site I can purchase to do this process? I'm thinking of buying a couple bricked phones and trying this out lol
SilentTweak said:
http://www.diygadget.com/universal-jtag-adapter-for-routers-modem-fta-and-more.html
Could I use this JTAG adapter? Or is there another adapter on this site I can purchase to do this process? I'm thinking of buying a couple bricked phones and trying this out lol
Click to expand...
Click to collapse
Looks like a 74HCT244....
I posted a link to a schematic for what is really the exact same thing -- should be in the other thread. It takes about 10 minutes to solder one of those up and you can make it for $2 in locally acquired parts.
Hey,
ezterry opened up another hacker thread...
Nice work mate
Anyway here's a schematic and some comments i once posted at the original JTAG on Dream thread.
http://forum.xda-developers.com/showpost.php?p=5110255&postcount=37
It's low cost LPT-adaptor and works very well with the MSM IO voltage of 2.6V.
Feel free to re-distribute
Maybe some soft tweaks are needed to integrate in openocd.
Once made a patch... but it's lost somewhere.
Cheers,
scholbert
Thanks
ezterry said:
No reason a parport adapter won't work, and openocd supports many part port adapters.
Also if you are more comfortable with other arm compatable software it ought to be easy to port the steps.. its just ram writes.
I just don't own any computers I can plug in Part port devices anymore.
scholbert from the other jtag thread may be able to give more info.
Click to expand...
Click to collapse
Thank you very much for the insights and also for all your work and knowledge that has been shared with the community.
BTW. Anyone know where to buy a parallel port JTAG in Canada (i hate customs) lol
Thanks again to everyone who posts in these forums
lbcoder said:
Looks like a 74HCT244....
I posted a link to a schematic for what is really the exact same thing -- should be in the other thread. It takes about 10 minutes to solder one of those up and you can make it for $2 in locally acquired parts.
Click to expand...
Click to collapse
I was searching that schematic without luck, can you please post the link here?
thanks!
kR105! said:
I was searching that schematic without luck, can you please post the link here?
Click to expand...
Click to collapse
Anyway here's a schematic and some comments i once posted at the original JTAG on Dream thread.
http://forum.xda-developers.com/show...5&postcount=37
Click to expand...
Click to collapse
If you want a true wiggler clone, this isn't...
I'll prepare another schematic...
Regards,
scholbert
ezterry said:
So a short recap for those not following along in the various threads.
The T-Mobile Phone in question
I've recently (off ebay) got a bricked HTC T-Mobile G1. (failed attempt to install the 2005 SPL.. (**sidenote)
Given it was a cheap phone it was a good candidate for jtag testing; after shorting something out on previous jtag work on my rogers dream. (the jtag port is the same on both phones.. and it did work on the dream for a bunch of tests before the incident)
Details of the de-brick are on this threadRogers Rom
Given the phone already has jtag attached (a little bit of a painful process) I decided to try unrooting a rogers rom on it before going to any other phone. So I took the nbh from the rogers installer (I still have the original 1.89.631.1 rom.nbh from when I created the hacked version which skipped the spl/splash1 portions of the flash.)
This flashed from the 2005 SPL without incident making the T-Mobile phone running a full rogers stack (splash image included) see op post for images of the phone/rom in this mode.Unroot (I know this is what you are here for)
So now with a fully locked SPL in place and jtag already set up time to hack out of the rogers rom to an EBI1 port!!
Prerequisites:
A) phone running locked roger rom 1.89.631.1 (actually as listed it will work for any rom on radio 3.22.26.17 and with offsets in my de-brick post other radios.
B) Jtag adapter.. I'm using OLIMEX ARM-USB-OCD.. however others will work as well.. my steps assume the openocd program on your computer which supports many USB/ParPort adapters. (my current cfg hopefully will improve but works for this hack.. note its for version "Open On-Chip Debugger 0.4.0" not the old cvs/svn version that is on the CD with the hardware)
C) outfit phone with jtag adapter.. this i will leave to another topic.. see the Jtag thread for the test points.
D) A HTC Serial wire.. I recommend without the +5 power line since blue light mode is sometimes hard to enter while the device is charging.. (information on my wire with links to parts. If you wish you can also attatch a USB wire to the USB leads which allows you to see serial output while flashing.. but ensure you can have the USB unplugged while the oemspl serial is in use.
E) 2005 SPL *.img file extract it from the zip file: http://sapphire-port-dream.googlecode.com/files/spl-signed.zip
MD5 (hboot.img) = cdf75d34e24937da1a8a84bcd72496c3
F) Recovery *.img .. your favorite flavor of '-R' version from this thread: http://forum.xda-developers.com/showthread.php?t=566669
G) a sense of adventure
Procedure:
1) Ensure the jtag adapter is hooked up to the phone
2) power on phone into blue light mode
3) attach serial wire
4) connect to serial console (mtty in windows, "screen /dev/<serial device> 115200" in osx/linux)
5) start openocd or other jtag application (openocd -f dream.cfg)
6) start telnet to the ocd: "telnet localhost 4444"
7) run the following:
Code:
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> [color=blue]halt[/color]
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x200000d3 pc: 0x0090861c
MMU: disabled, D-Cache: disabled, I-Cache: disabled
> [color=blue]mww 0x0090379C 0xea000013[/color]
> [color=blue]mww 0x9029d8 0x0[/color]
> [color=blue]load_image [b]<pathto>[/b]/hboot.img 0x0[/color]
No working memory available. Specify -work-area-phys to target.
no working area available, falling back to memory writes
524288 bytes written at address 0x00000000
downloaded 524288 bytes in 11.635834s (44.002 kb/s)
> [color=blue]mww 0x00000c0c 0x98000C4C[/color]
> [color=blue]mww 0x00000c08 0x98000C4C[/color]
> [color=blue]mww 0x00000c04 0x98000C4C[/color]
> [color=blue]mww 0x00000c00 0x98000C4C[/color]
> [color=blue]resume[/color]
The offsets are based off my de-brick post
* 0x0090379C is the CID bypass point for 3.22.26.17
* 0x009029d8 is 4 less than the previously defined breakpoint for 3.22.26.17 SPL modification (for other radios subtract 4 from my breakpoint location);
This is the location of a subroutine call to load the SPL.. since we are going to load it our self we want to nop the instruction.. no 0x0 is not the nop instruction.. but it will achieve the same results (and lack their of).
* load_image will load a file into the phones ram; point this at the hboot.img you downloaded as that is what we want to run
* 0x00000c00 to 0x00000c0c is the switch jump table in the 2005 hboot image once loaded for the boot mode.. we are forcing modes 0-3 to ruu/fastboot mode.
* then we can resume the CPU and optionally kill openocd.
8) into the serial termal run command "?" this ought to now output help on many commands (before it would only say invalid command)
9) run command "cego"
<phone will now boot into the ram image of 2005 SPL; display splash image (if screen is connected) and enter fastboot mode>
10) remove serial wire and attach USB wire.. or plug in usb part of USB/serial hybrid wire.
12) "fastboot flash hboot hboot.img"
13) "fastboot flash recovery recovery.img" (the ebi1 RA recovery)
14) "fastboot oem powerdown"
Now you can boot into recovery and flash your favorite EBI1 rom.. or if you don't like EBI1.. follow the EBI0 installation instructions
** sidenote: To packagers and those making processes.. Given all I have seen to date.. whenever possible flash radios and SPLs via fastboot not recovory zip files..
If you are stuck on a splash screen on boot.. both the SPL and radio are working.. they are just usually stuck in an invalid mode.. which is less likely to happen if flashed by fastboot.. this particularly applies where the 2005 SPL is involved.
Hacking can be fun.. but this hacking is not cheap
If interested in giving a donation feel free to contact me
Click to expand...
Click to collapse
how build device to reflash dead G1 ? electro scheme?
some buy exterry the solderless jtag adapter
mentioned in the other post
or he will end up with a huge collection of phones
I'll even chip in
my dream is fine and rooted but my magic was shipped the rogers ways
so I am waiting with great hopes for the jtagless option
and more than willing to help where I can
My phone is only three color mode, if i switch on. I try different rom upgrade but nothing. What i can do?
A little more information is needed:
What does the 3 color screen tell?
What happens if you execute a ROM update?
How do you try to make the ROM update, shipped ROM (which) or a cooked ROM (which)?
Has the device ever worked?
Which ROM was on the device before it got stuck in bootloader (3 color screen)?
Tri-color screen meant by bootloaderit (red, green, blue). When I try to update the ROM, it shows that it would be done, but the re-launch the bootloader all the time. Try a different ROM, which is designed for the HTC Qtek 8310 and the Tornado. WM6, WM61 and WM65. WM5 device worked before, more detailed version i dont know. letter on the screen IPL: 2.00 SPL: 2.00.0009
It seems that the loaded ROM does not succeed to load. If you load a shipped ROM everything outlined below should be done automatically for you, so if that does not work as well, then the device may be broken. So check first if you can load a shipped ROM again.
For cooked ROMs you need to prepare the BINFS to match the size of a ROM before you load it. As you succeed in loading any ROM, the device seems to be CID unlocked already. Check the following:
Connect the device in bootloader mode. Switch off, then keep camera button pressed and insert USB cable.
Disable USB for Active Sync (Connection settings of AS).
startup a terminal program that can connect via USB (e.g. TTerm pro)
connect ot the USB port
press enter
Command prompt appears
enter "info 2" (no quotes) enter
read the last line, it should give something like "HTC SuperCID". If not, then you must CID unlock the device first. Lookup the relevant threads for the cooked ROMs or search for Lokiwiz.
If the device is already SuperCID, then you must match the BINFS formatted size to be larger or equal the ROM size (OS partition). For most cooked ROMs it is the binary file size. Relevant actions are also described in some cooked ROM threads, e.g. mine - see my signature.
What is shipped ROM? Original Rom? I do not have it.
Tera Term
info 2
GetDeviceInfo=0x00000002
+ SD Controller init
- SD Controller init
+StorageInit
CMD55 failed
+ SD Controller init
- SD Controller init
+StorageInit
CMD55 failed
HTCSBPT_0501 Lqœ»HTCE
I try unlock SuperCID with program lokiwiz02b.
But nothing happend.
machinagod's HTC Wizard Unlocker v0.2
NOW WITH CID Unlocking POWER!
--------------------
WARNING: This tool is highly experimental!
I will NOT be held responsible for any problems caused by this tool.
--------------------
Thanks to xda-developers, spv-developers, and especially itsme by the work they
released. This solution would not be possible without them.
--------------------
U. Unlock
L. Lock
C. CID Unlock (SuperCID)
Q. Quit
--------------------
Type the letter and press Enter: c
CID unlocking mobile... DO NOT DISCONNECT UNTIL THE PHONE REBOOTS!
What i try next?
IF your OS is not up, then the lokiwiz will not do anything to your device!
With THIS status you should not succeed in doing any update or format your BINFS. You first need to get the original OS up and running again before you van get any further on changing your OS. The steps to take are:
Get old OS running up again
Application unlock the old OS
CID unlock the device (backup your *.bin files!)
load new OS
1.) is your problem currently. There are several ways to achieve this, try a hard-reset first, this should work for your device:
switch off device
press L+R softkey and hold both
switch on device and keep L+R softkey pressed
wait until prompt and act accordingly
device will reboot to OS
OK now?
I do not have the original OS or even the old OS. After a hard reset as well as the OS does not come up.
# Switch off the Device
# Softkey Press L + R and hold Both
# Switch the device and keep L + R softkey presses
Press 0 to restore factory default. Other key to exit
I press 0
After hard reset load the bootloader again.
OK, then you need to load the CID matching old OS via the shipped ROM standard procedure. Look to: http://www.shipped-roms.com/shipped/Tornado/ and get 8310_2090_253121_020900_to_dan_eur_ship.exe
Execute it on the PC while the device is connected in bootloader mode. If that does not work, then try other ROMs in the same directory until you succeed with the loading.
Mind that a first boot takes 3-5 minutes, so be patient if the bootloader is not coming up any longer. Also do not interrupt the ROM loading in the first steps when the upload has started. It is normal that there are phases where the progress bar does not move. I think the sequence is per partition (IPL, SPL, Splash, OS): load to RAM (bar progressing), load from RAM to ROM = flashing (no bar progress, but color change of bar at the end). The large OS partition is loaded at the end of the sequence so the second step will take some time - be patient.
Good luck!
I try all ROM's but always give me ERROR 294 INVALID VENDOR ID.
And now the phone does not start anymore. No picture. I dont know what happend
This seems to prove that the device has something broken.
Make sure that the battery gets charged while the device is off. Despite the device was connected to USB all the time there is no charging happening in bootloader mode. Wait until the green light is there again before you continue - power drain in bootloader mode is quite heavy.
When none of the shipped ROMs work for upload, it really gets hard to load back an OS running on that for further steps :-(
There is a procedure called "Gold Card method", the rough procedure is (only did that once years back - so this is no step-by-step guide):
Prepare the card so that the bootsector contains the magic device specific "Gold Card" signature. For that you need a trial version of PSAS, and a working windows mobile device(!).
then you would have to load the *.nbh file that gets uploaded to the device (and fails) to that mini-SD card root directory,
rename it to TORNIMG.NBH there
load the card to the device,
then reboot to bootloader (Camera + on)
and hope it gets it loaded
A detailed procedure is described for the Excalibur device but this works equally well for Tornado if you adjust the relevant parts (PSAS is the success of QMAT). Mind that the miniSD card should be in really good condition (fresh full format, check that the file loaded can be read byte-identical from it). If the loading from the card fails or corrupts the IPL/SPL while loading then your device is really bricked. It happened to me with an Excalibur (read the whole thread linked above) - so be extra careful (though - what do have to loose?)!
Finally the long promised kitchen with dual language support (English/German) for the Tornado. It benefits from the experience I made with creating the Hurricane kitchen and is a merge from the (unpublished) bi-lingual older Tornado Kitchen and the one for Hurricane. It is still the same old OS Version as in my previous kitchen (and the one from NitroGenious) - but some things have improved:
put the kitchen anywhere in the path, no fixed path needed
support for German language in all system menus and applications, including all tweaks and OEM applications (as far as available).
full Direct 3D support (TI drivers work in this ROM)
full support for all 4 key devices and WMP with selectable keyboard driver
still memory tweaked as in the previous kitchen, but some files have been re-compressed without icon compression - to speed up explorer icon access.
The related batch for the _squeezer (UPX) was improved.
quirks left from previous kitchen have been resolved
some more tweaks
reorganized the OEM and SYS folder to have only true generic OS parts in the SYS folder - this should ease future OS porting
For the basic instructions and explanations, please read the older Tornado Kitchen threads my previous Tornado Kitchen and NitroGenious Tornado Kitchen.
For preparing yourself about what cooking is and get started with understanding what you do, look at my Beginners Guide to Windows Mobile (prepare for cooking).
The needed files are shared at mediafire. Make sure to push the "(i) Details" button on top of the list.
You also find a pre-cooked ROM with common content (e.g. NetCF 3.5), so you may want to try that before cooking yourself. Don't forget to format the BINFS correctly before loading the new OS.
The history is:
- Nitrogen Kitchen
- my older Tornado Kitchen
- my Hurricane Kitchen
- this kitchen
Future may be:
- Tornado cooking based on OSBuilder
- Typhoon cooking based on OSBuilder
- mind that Hurricane will not cook with OSBuilder
The ready-made ROM is shared at the same folder as the kitchen. To get a quick start you have to:
For a device that has never seen a custom ROM, download the file "tobbbie_prepare-flashing-(one-time-per-device).zip", unpack it to any folder and find the tools needed for accepting custom ROMs.
For an already Super-CID device, get the file "tobbbie_nk-default-eng_ger-corrected_WM6.zip", unpack it in the same folder as the other zip. Then:
Run "1 as.exe" and kill active Sync
Remove a memory card from the device if there is any inside.
Put the device in bootloader mode (switch off, then press and hold camera key while connecting USB) and connect to the PC
Run "2 mtty...exe" on the PC - you should see a "USB" button on the right of the pop-up coming after some time, press that. In the terminal window press enter to get a prompt. If the USB button is not there, make sure Active Sync is not running.
Enter "info 2" (no quotes) and press enter, you see some lines of feedback, there must be something with "HTC Super CID"
Enter "format BINFS 1c00000" (no quotes), enter - wait for completion
Enter "ResetDevice" (no quotes, UPPER and lowercase exactly as given)
Wait for reboot of device, you get the device in 3 color screen now again
close the terminal window (Ctrl-F4) or the whole mtty (Alt-F4)
Start "3 ROMUpdateUtility.exe" and follow instructions
...reserved for even more further info
I don't understand how to let work the german language on my phone. i download 3 package but i don't know how to begin.
Hm... seems like you have no background on mobile phones ROM update?
The reasons what to do and how to do it are explicitly described in my first kitchen thread in the first post: http://forum.xda-developers.com/showpost.php?p=5386878&postcount=1
Sequence is:
prepare the device that the current OS allows access to system resources that allow later to open the door for cooked ROMs (application unlock)
open the door for cooked ROMs (Super CID) -> this is permanent for this device
flash new ROM (can be any cooked ROM).
If you want the German ROM you find the .nbf file in the mediafire share listed in the first post of this thread.
Please report on your:
device:
actions done so far including results of each step
Hello,
but i do already all this steps with success and my phone works but only with english language.
i also load the german nbf file but its remain only the english language. in in the mediafire share listed, are so many files. What i need exactly? probaly i try it with the wrong file.
p.s. Sorry for my bad english. Im german
Then you are at 95% and miss the simple device configuration, go to:
Start: Settings
-> Regional Settings
--> Language: Deutsch
--> Locale: German (Germany)
There (if you like):
--> Long Date style: middle option (I patched the NLS for this to be available)
You get 2 infos to restart the device (for Language and for Locale), confirm with OK.
Then leave the settings with "Done".
Now press short power: select "Reboot"
Now you have set the device to German.
For Certain applications you may have to do the setting to German within the application, e.g. in CE-Commander - some do not have the option to switch to German.
I also do this. If i go to settings, i can only select the english language and not the German.
In Locale i can select Germany.
p.s. i used this file: tobbbie_nk-default-eng_ger_WM6.nbf
You have to load the correct .nbf file!
The folder where the romupdateutility.exe is located must only have ONE .nbf file contained, otherwise you cannot predict which will be loaded. Look up the first post in this thread for the right file.
Most probably you loaded the .nbf from the first released plain English ROM.
To load a new ROM you must:
1.) format BINFS <right size>, for the ROM located as listed it is "format BINFS 1c00000"
2.) ResetDevice -> Bootloader
3.) rumupdate... with right .nbf
CID Unlock is permanent, latest SPL and Radio as well - no need to repeat any of these actions.
All details are listed in the relevant ROM threads.
Sorry but i don't understand which right file you mean.
The needed files are shared at mediafire? There are 5 files with many folder.
please have patience with me
You managed to load the pure English ROM - that is a start and you seem to have succeeded with most tasks:
- CID Unlock is done: otherwise you would not be able to load a cooked ROM
- WM6 ROM is loaded: only English as Language Selection
You now only need to re-do the tasks to format the BINFS and then load the ROM to the device. In the FLASH folder you should delete the old .nbf file and replace it with the one in the ZIP here: http://www.mediafire.com/?vdsgjg13v9cfnsj.
Please look up post 2: http://forum.xda-developers.com/showpost.php?p=13176294&postcount=2
I have simplified some things and also corrected a minor bug in the ROM and kitchen that had the backlight stay on while mediaplayer was on playback.
great job, mate!
until here:
# Run "1 as.exe" and kill active Sync
# Put the device in bootloader mode (switch off, then press and hold camera key while connecting USB) and connect to the PC
# Run "2 mtty...exe" on the PC - you should see a "USB" button on the right of the pop-up coming after some time, press that. In the terminal window press enter to get a prompt. If the USB button is not there, make sure Active Sync is not running.
# Enter "info 2" (no quotes) and press enter, you see some lines of feedback, there must be something with "HTC Super CID".
everything ok.
in the windows appears:
Cmd>info 2
GetDeviceInfo=0x00000002
+ SD Controller init
- SD Controller init
+StorageInit
***** user area size = 0x3C8C0000 Bytes
HTCSSuperCID ' HTCE
But if i enter "format BINFS 1c00000" without quote, i have no completion.
cmd>format BINFS 1c00000
or i enter ResetDevice, my device dont reset.
What the error?
Remove the memory card from the device and then re-do the action.
You have a card of 1 GB in the device - you can find it here:
+StorageInit
***** user area size = 0x3C8C0000 Bytes
The device must not have a memory card inserted while doing these things.
I remove the memory card but i have the same problem:
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>format BINFS 1c00000
Cmd>ResetDevice
Cmd>
This is weird - what device do you have?
Did you update your SPL and Radio to the latest versions (as advised in the "...one time per device" ZIP)? What is the SPL Version on your device?
If i put the device in bootloader mode, there stand in the red color: Tornado IPL 2.00, Tornado SPL 2.00.0014. In the green color Tornado IU.
This is ok - as it should be for IPL and SPL. Now check the following while in bootloader mode connected to mtty:
try to enter just "format BINFS" <enter>
What is the result (should be ok after a short while)?
enter "format BINFS 123" <enter>
What is the result (should be an advice on the valid values as 123 is not a valid one)?
If the first one works, but the second does not, you can still load the ROM, however the free storage space (for installing programs) will be less than what it could be.
Again for curiosity: which Tornado device is that (O2 XDA phone or Qtek 8310)?
Hello,
this is the result:
Cmd>format BINFS
Cmd>format BINFS 123
Cmd>
i have a O2 XDA
thank you for the help
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_profileRead 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.