Related
Question about ROM flashes.
I'm actually an IT professional in the work related field, so any basics need not be explained. I am still new to Windows Mobile devices and would like to know what this means for my phone.
The way I view a "ROM" is as a firmware, or static programming on a chip. Maybe even a CMOS imprint. In this field, such things are semi-permanent at a component level. For instance, you don't download a .cab file to upgrade your bios (as many "ROMS" seem to come in .cab files), you boot your system on a floppy and run an application that flashes your CMOS with the new image.
What would we assume the "ROM" is on Windows mobile phones? Is it a chip hidden inside of the phone, separate from the primary memory? Is it simply considered all that is in the \windows directory? I don't see why .cab files can flash the ROM.
This leads me to the question, if you do a hard-reset, I assume there's secondary memory on the phone with the \windows folder and all the factory defaults. The memory must serve no other purpose other than to harbor these defaults in the need of a hard-reset. Does flashing your "ROM" also apply changes to this chip containing the default OS image?
Hi, here a short description:
ROM:
The ROM is quite similar to a computers harddisk AND RAM (All-In-One), but the OS has to and additional software can be integrated via flashing and is therefor fixed. All data you flash will stay in the ROM after a Hard-Reset.
Some ROMs also contain a Bootloader-ROM and/or a Radio-ROM
Bootloader-ROM:
This is quite similar to a computer's BIOS
Radio-ROM:
The firmware to your PDA's built-in connection devices (e.g. GSM, Bluetooth, WLAN,...)
Hard-Reset:
A Hard-Reset is similar to a comlete reinstallation. Some computer vendors add a recovery CD/DVD to their products. On a Windows Mobile Device the Recovery-disc is integrated in the ROM and will be automatically installed during a hard reset.
And to complete this one ;-)...
Soft-Reset:
A Soft-Reset is similar to a cold restart of your computer. By the way, there's no possibility to "shutdown" Windows Mobile like you are used to with Windows XP or Vista.
Oh, and you cannot install a ROM using a cab-file. Cab-files are "executables" to install additional software. They can only be installed on the device. ROM's have to be installed from a connected computer (There's also a resolution to install a ROM from a Storage Card, but i am not used to it and cannot give you more information about this. But you'll find it, searching in the forum).
jon_k said:
Question about ROM flashes.
I'm actually an IT professional in the work related field, so any basics need not be explained. I am still new to Windows Mobile devices and would like to know what this means for my phone.
Click to expand...
Click to collapse
Me Too.
jon_k said:
The way I view a "ROM" is as a firmware, or static programming on a chip. Maybe even a CMOS imprint. In this field, such things are semi-permanent at a component level. For instance, you don't download a .cab file to upgrade your bios (as many "ROMS" seem to come in .cab files), you boot your system on a floppy and run an application that flashes your CMOS with the new image.
Click to expand...
Click to collapse
Yes, it is firmware on the chip, but like a BIOS, it exists after the phone is off, the battery removed, etc. The stuff in the cab files that you install doesn't. Well, let me retract that. The stuff in the cabs and your data stays there after a soft reset, and removing the battery (at least for a short while, YMMV), but my experience has not been that the data stays there after the battery is out for a while (again, YMMV).
jon_k said:
What would we assume the "ROM" is on Windows mobile phones? Is it a chip hidden inside of the phone, separate from the primary memory? Is it simply considered all that is in the \windows directory? I don't see why .cab files can flash the ROM.
Click to expand...
Click to collapse
Yes, it is a chip. Most of the time, they don't use discreet transistors for these time of things. They are prohibitively large and expensive to solder together to make the memory, not to mention power hungry.
To answer your second question, if you peruse the various ROMs here, you will see the following:
Base operating system: This is a common denominator. This is Windows CE/ Mobile edition, WM6, whatever you want to call it.
Additional CABs: This is the flavor the chef uses in his/her kitchen to make the ROM do what appeals to them (and their audience). These can techniclaly be split out and individually installed if the cook puts them as a cab file that you copy to the phone and install from that file downloaded.
jon_k said:
This leads me to the question, if you do a hard-reset, I assume there's secondary memory on the phone with the \windows folder and all the factory defaults. The memory must serve no other purpose other than to harbor these defaults in the need of a hard-reset. Does flashing your "ROM" also apply changes to this chip containing the default OS image?
Click to expand...
Click to collapse
What will happen when you hard reset is the ROM that was flashed to the phone will be as it was when you first burned it to the phone. Here's an example: You buy the Kaiser marketed as an AT&T Tilt on 1/1/08, use if for 6 months, and on 7/1/08, you hard reset it. It will be the same as when you turned it on for the first time.
Another case: You buy the phone on 1/1/08, and download a ROM from Dutty, or whomever, and you carefully follow the noob instructions (like I did), and flash it on 1/2/08. You do a hard reset on 7/1/08, and now the phone is the same as when it was last upgraded, so it will be the 1/2/08 version that it goes to.
Clear?
Hope this helps, and if there are others that want to correct me, please do so.
Fairly good explanations.
It makes a bit more sense now.
I'll post my new understanding of the control structure and functionality based on everyones post above. If you want to confirm, deny, or alter any of my perceived facts I'd appreciate it! I just like to know a basic understanding of the device functions internally so I can be educated when tinkering with things.
The radio ROM = ROM that controls the radio. Contains frequency ranges/broadcast tweaks for different locales, probably if tweaked can also allow illegal higher wattage transmission power. Some interesting (and surely FCC illegal) hacks are probably available here.
The device ROM - the upper level functions of the phone. Probably has support for the type of WIFI and bluetooth adapter you have. Has to have compatibility to interface with the radio ROM for phone functionality to be supported. Also is what interfaces with the GPS radio, probably the phone, links the keyboard to the OS, etc. Probably handles API between radio ROM and Windows mobile?
The Windows Mobile OS, which is the operating system itself. It communicates with the ROM, and is limited by what the ROM is limited by. Any .cab's or software retrieved here will enhance the OS, nothing more. A hard reset will bring the OS back to it's original state. (Though ROM upgrades remain.) Any cabs installed or changes to \windows in general made will be lost during a hard reset. It restores all content under \windows to it's default state.
Sounds about right with my new understanding. I think for now I'll avoid flashing the ROM. I'm pretty content with modifying the Windows registry hive since it can easily be restored with a hard reset if I bork up a registry key. Unlike the registry, a ROM if a member here misses something (I doubt they're working with much device documentation) a small coding mistake by them could ruin the phone.
Maybe I'll be more prone to start flashing ROM's if there's a way to extract the current ROM for my phone. Perhaps I can update the ROM through ATT or HTC, and use a packet sniffer to sniff the location (likely http URL) of the ROM file.
One further question though,
Until several minutes ago I thought the ROM simply contained device drivers, etc. Stumbled upon this post however.
rkorzuch said:
Tool worked perfect on my AT&T Tilt. Just installed the HTC ROM. Much nicer than the AT&T ROM.
Click to expand...
Click to collapse
I'm now assuming the ROM contains the OS that is flashed on to the internal storage card as well, with it's own custom branding on the OS, own default application set, etc. As well as it's normal functioning with device communication etc. Is this safe to say this is how it works?
jon_k said:
One further question though,
Until several minutes ago I thought the ROM simply contained device drivers, etc. Stumbled upon this post however.
I'm now assuming the ROM contains the OS that is flashed on to the internal storage card as well, with it's own custom branding on the OS, own default application set, etc. As well as it's normal functioning with device communication etc. Is this safe to say this is how it works?
Click to expand...
Click to collapse
Yes jon_k,
The ROM contains the WM OS. That is what the cooks are changing primarily (more specifically, most of them change/add/delete the bundled apps that come as part of the shipped OSes). Most now are also expanding the RAM/storage portion of the ROM to allow for more usable storage. More and more cooks are also ripping out some of the MS bloat .
You should do a hard reset and then force a soft reset before it does the device customization part. You will end up with a Tilt with none of the AT&T bloat (game demos and such). If you don't like it, hard reset again and let it finish.
If you get real adventurous you can install HardSPL and one of the cooked ROMs (or the HTC one).
i was just trying to get a grasp on how to flash bootloaders on android devices. I have got a grasp with how to do it on old WinMo HTC devices, but there seems to be a lot more information regarding the various Android handsets. So here is the rundown of what I have found so far:
General Android: it appears that almost all android phones have the ability to flash from an SD card (by putting an update.zip on it). Can this reflash the bootloader? i don't see a reason why not (the bootloader should be in memory when the updater is running, so the flash should be writable) but having said that, i know on the old HTC devices that I have used, it wasn't possible (you had to load a softSPL or a diagnostic SPL to then run the flashing). Also, would anyone by any chance have a good understanding of what is in the update.zip? i see it referenced a lot, but as far as i can tell, it looks like it is just packages and directories and stuff to copy. Most of the posts I have seen regarding flashing also try replacing the recovery image, and then booting into recovery and telling it to recover. Does this work for bootloaders or just ROMs?
HTC: this appears to be the same as the old WinMo 6 devices I have used. You can use the RUU utility, supply it with an nbh file, and there are no problems. Outside of the Incredible S it would also appear that they don't have any kind of signing or anything to worry about. As such, you can see the SPL in cleartext and is in cleartext on the phone (I am guessing anyways). One question I do have is I have the ancient NBHGen used for the Kaiser (also worked for Hermes, Trinity, etc.), will that work with say the HTC Hero (or insert modern phone here)?
Samsung: Samsungs SBL as far as I can tell is equivalent to the HTC SPL (much the same as the HTC IPL = Samsung PBL). I have actually seen an apk that supposedly updated the SBL for Samsung. Like HTC, it also appears that they leave everything in clear text. If i am not mistaken, Odin is the tool of choice for reflashing on Samsung devices (any good tutorials out there for it and its file formats? i haven't actually looked too hard at that yet)
Motorola: I dont wish to stir up any anger (especially since most of what I read is on the Droid X), but Motorola is the one that is the hardest to find real info on. Motorola, on their more popular phones, appears to have made a habit of adding aggressive anti-tampering to their premier phones (at least after the original droid). I don't believe that their SPL equivalents have been cracked, but I also can't find a straight answer about whether their bootloaders are signed or encrypted (or both). They are two different things, but have been largely used interchangeably on most forums. They also have eFuse protection. I have looked at a few of the SBF files in a hex editor, and they don't appear to be ARM assembly. That said, I wouldn't believe that it is encrypted as there is cleartext within it. This leaves a couple of options. either the data moved is encrypted and it copies over encrypted data that gets decrypted at boot time (that seems like a massive waste of CPU cycles, but i wouldn't put it past them to do something like that). Or it could mean it gets decrypted by whatever loads it onto the phone. And lastly, it could just be x86 assembly (which i wouldn't recognize by looking at it). The last one seems to be the best fitting, but it doesn't answer whether or not it is encrypted on the phone. Since I haven't found an SBF file that contains just a bootloader, i haven't really had the chance to examine it. I also have not sen a way to flash a new SPL to a device (even a more open one like the original droid, which i believe is still locked, just not signed/encrypted).
file formats: this is also kind of confusing. I mentioned the update.zip above, but i have also seen people referencing ,bin and .img and all kinds of other files. If i am not mistaken, a bin and img file are the same with a different extension. Straight up binary, though i believe that the img files are supposed to be partition images. Is that accurate? and are SBF files executable? i swear i saw somewhere that people were running them, though it could just be my imagination...
I know there is a lot there a lot of information there, but I just wanted to check and make sure it is accurate, so I don't sound like a noob to my boss when I present it.
Many thanks!
There are a few of these guides around, but I thought to write my own. Hope it will be helpful! I'll keep the most up-to-date version on my site.
Rooting Android: What Is it?
If you've heard about "rooting" your Android phone, and are confused by what exactly it does, or don't understand the instructions you found on an obscure forum or blog post somewhere, this guide might help you make sense of things.
What Is "Root"?
"Root" is the name of the default administrative user in Unix. The user named "root" can do absolutely anything: edit or delete any file, start or stop any system service, and also add, remove or change the privileges of other users, so that they, too, could perform the same operation.
So, user "root" can actually bestow administrative privileges on any Android user, including the default one you use normally on the phone.
When you buy an Android phone, it normally does not let you login as user "root".
What Can User "Root" Do?
Your phone is really a general-purpose hand-held computer. People have written apps for it that can do the things like this:
Turn it into a wireless internet router, connecting to your 3G/4G network on one end, and broadcasting a wifi hotspot on another. You can thus connect your laptop to the internet from anywhere. "Tethering," but without cables!
Lets you overwrite any of the Android system files, customizing it to your heart's content. This lets you customize the built-in fonts, colors, keyboards, etc.
Lets you install newer versions of Android, beyond what your phone's vendor has provided.
Why stop at standard Android? Because Android is an open source operating system, people have been able to modify it to add features far and beyond what Google has put in it, as well as offering better performance in some situations. With administrative privileges, you can just flash an entire new Android ROM to your phone. A very popular one is CynaogenMod, which is based on Android 2.3.
Install various networking servers and clients, such as QuickSSHd to allow logging in to your phone over the internet, or CifsManager, which lets you access Windows shared drives from your phone.
Who knows? People might think of new users for these hand-held computers, uses that would require full access to all features of the phone.
Why Won't My Phone Normally Let Me Login As "Root"?
First, for reliability -- as far as you're concerned.
Imagine if your phone automatically gave you administrative access. This means that any app you install can do anything it wants to it. Obviously, unacceptable.
An alternate solution is available in newer versions of Windows and other desktop operating systems, which require you to enter a special administrative password whenever a program is trying to access secure parts of your computer. This is annoying enough on a desktop computer: on a phone, it would again be unacceptable.
So, it makes sense -- for your sake -- to disallow any administrative privileges.
Second, for reliability -- as far the phone vendor is concerned.
A smartphone, unlike a PC, is an expensive consumer device with an explicit support contract. People normally and frequently return phones to the shop if they stop working properly, or call customer support to get assistance. There's a huge cost for the vendor to maintain this support network.
Think for a minute what would happen if any phone user could login as "root" and delete any system file: you would have broken phones everywhere, frustrated consumers, and clogged support networks. Indeed, "rooting" a phone pretty much voids your warranty as far the vendor is concerned.
I Understand the Risks and Am Willing to Void the Warranty, So Why Can't I Login As "Root"? It's My Phone!
Even if logging in as "root" were an advanced feature, hidden away somewhere in the menus with thousands of warnings about possible dangers, you can bet that many non-advanced users would find it. When their phone breaks, you bet they will be angry, and will not care that the warnings were there. As far as they would be concerned, this "root" thing is a feature of their phone, and if it can break the phone then it shouldn't even be there.
And there's a third party who has a business interest in denying you "root": the telecommunication carriers. Their business model is designed around typical consumer uses of the phone, and they do not want it to be too powerful. For example, a "rooted" phone can let you tether it to a laptop, so that your laptop gets its internet access. But, carriers typically sell special "laptop sticks" for that purpose specifically, and these usually are more expensive than phone plans, because they take into account the much heavier bandwidth that laptop users tend to use. If everybody could "root" their phone and tether it, this product -- and source of revenue -- would be irrelevant.
So, Phones Don't Come with a "Root" User?
Android is based on the Linux operating system, which requires the "root" user to function. It's there. However, the vendor has tried to hide all the normal ways to access it. The "root" user is there, it's just "locked."
What Is "Rooting"?
In the context of Android phone, rooting means more than just letting you log in as the "root" user: it means installing a set of tools so that any of your programs can access "root" when then need to and you allow them.
The result is that "rooted" phone works just like Windows, in that it will ask you for permission (but not a password) whenever an app is trying to get administrative privileges.
Fortunately, once you gain access to the "root" user, it's very easily to install a set of standard apps that let you implement this feature, specifically the Superuser app.
How Do I Root My Phone?
Nothing in software can be truly locked down, and hackers have found ways to get "root" access on any Android phone on the market. There are quite a few holes.
But, these methods vary a lot and are different per phone. It's easier on some phones than others. It's often risky, too, because a misstep could potentially "brick" your phone -- making it so that you cannot boot into Android. "Unbricking" is possible in some cases, but not in others. Take care!
Search the internet, and you will likely find various blog and forums posts with instructions for rooting your particular phone model.
This is not a guide for rooting your particular phone model. Instead, it is a general description of what rooting is and how it works. It can help you understand the rooting instructions you find.
Any Downsides?
Well, first of all, there is the risk of bricking your phone. You might want to make sure that someone you know with the same model phone as you have has used the method before. Or, read about it in the internet forums, and make sure that lots of other people have used this method successfully.
Also, you may void your warranty: of course, this would only happen if customer support looks closely at your phone and notices that it has been rooted. It's a good idea to look at these rooting guides to see if there is an easy way to un-root the phone, or at least return it to factory settings.
Finally, there's the issue of "firmware updates" coming from your carrier. Sometimes they will work fine with rooted phones (as long as custom Android ROM has not been installed on them), but depending on the rooting method it may mean that won't work fine anymore. "Not working fine" can mean that the upgrades simply won't run, but it can also mean that the upgrades would fail terribly and brick your phone. Generally, if you have rooted your phone and are getting an "Update Available, Do you want to download?" message from your carrier, don't just say "yes," instead check the forums to see the experience of other people with rooted phones with this update. Generally this problem seems rare, a result of a very poor upgrade package from the vendor -- the usual case is that the upgrade simply won't work.
Don't worry too much: with a rooted phone (and a good Recovery program, see below) you will likely be able to install the upgrade yourself, and possibly better upgrades to more advanced versions of Android than your vendor provides.
How Rooting Works
First, let's understand how the locking down happens.
Your phone actually has more than just Android installed on it. There are, at minimum, three and usually four "partitions" in which entirely different programs are installed. Android is just one of them.
The Boot Loader
The first partition has the boot loader, the very first program see when you turn on the phone normally. The boot loader's main job is simply to boot other partitions, and by default it just boots the Android partition, commonly called the ROM (described below). So, you don't really see the boot loader for very long.
However, all phones allow for a special way of turning them on -- for example, holding the volume up button while pressing the power on button -- that shows the boot loader menu.
When you're there, you can actually choose if you want to boot into the Android partition, or you can boot into the Recovery partition (described in detail below).
The interesting thing about the boot loader is that it is very, very simple. It has no mechanism for users and privileges. One way to look at it is that it always is "root," and in fact can't be anything else.
Sounds like a good place from which to unlock your phone! Unfortunately, most boot loaders are too simple.
One exception is the boot loader found in Google's Nexus phones, and in a few other developer-friendly phones. These boot loaders can actually communicate with a PC over USB, and support writing data to partitions ("flashing" them), as well as booting from them. With this feature, you can flash an unlocked Android ROM to the Android partition, and you're done! Well, the challenge is just to find such a ROM that works well with your phone...
Most phones don't have such a flexible boot loader. However, getting into the boot loader menu is important, because it lets you boot into the Recovery partition, detailed next.
The Recovery Partition
As its name can tell you, this partition is mostly for customer support: the Recovery program can be used to return the Android partition to its factory settings, which can solve a lot of problems with faulty phones, or phones that were infected by bad apps. It can also format the SD card partition.
Some Recovery programs can also install special phone upgrades from the SD card, that write directly to ("flash") the Android ROM partition. Obviously, free access for anyone would allow rooting, so vendors make sure that Recovery would only accept official upgrades. But, one way to root a phone would be for hackers to find a way to create such an "upgrade" that the Recovery program would accept.
There's quite a lot of variation in Recovery programs out there: every vendor has their own idea of which recovery features would be useful for their customer support team. Boot into yours and take a look! It's harmless, unless you actually choose one of the recovery options...
Like the boot loader, the Recovery program is always in "root". A hacked Recovery program could let you flash an unlocked Android ROM, or run any "upgrade" you like. So, in addition to just "recovering" an unusable phone, it can help you "recover" the "root" user that has been locked from you!
A good Recovery program is very useful for customizing your phone, beyond just rooting it. By far the most popular Recovery program is Clockwork Recovery, also called ClockworkMod.
Some rooting methods begin by finding a way to flash ClockworkMod to your Recovery partition, from which you can then run an "upgrade" that roots your phone. Other rooting method find another way in, but still recommend you flash ClockwordMod as soon as possible, because it's just so useful for customizers.
You will not find a homepage or an "official" way to download ClockwordMod: carriers obviously do not want you get have easy access to it. But, search around, and you will find one appropriate for your phone. The ROM Manager app can also flash it for you, assuming you are already rooted.
The SD Card
This is another partition, entirely for you. It is not protected in any way, and you have full access to reading and writing files on it.
For many phones, this partition does not exist unless you physically install an SD card. Some phones have a built-in SD card.
The Android ROM
Finally, the most important partition on your phone! When the boot loader starts the Linux operating system (the "kernel") that sits underneath Android, one of the first subsystems to come up is the security system. From then on, the "root" user will be used to start various user-level subsystems required for the phone to function.
Eventually, the default user will be started, and that will be used to run your apps: the status and notification bar that appears on the top of the screen, the settings manager, the virtual keyboards, etc. Finally you get the home launcher, from which you can launch all the other apps on your phone. None of these programs run as "root", so you are effectively locked from administrative privileges.
The Linux operating system can set security permissions per file. So, indeed large parts of this partition are restricted to be read-only by any user except "root". So, if you boot into Android, none of the apps you run will be able to change these system files. The rest of the partition is readable-and-writeable, and generally functions just like the SD card partition, though it's usually much smaller.
Of course, if you boot into Recovery instead, you will be able to write to these files, because you are "root" there. That's why ClockworkMod is so useful for rooting your phone!
Most Android apps run on yet another layer, a virtual machine called Dalvik, which is a heavily modified version of the Java virtual machine found on previous generations of cell phones, as well as on desktop computers, servers, and many other devices. Definitely, everything you install from an app store will run on Dalvik. Dalvik is a tightly controlled environment in which privileges are carefully controlled per program, beyond what the Linux operating system provides. Not only do apps not have administrative access to the phone, but they can be limited in access to wifi, cellular access, and your data.
Except... that Android does provide a way for apps to request administrative privileges. In locked phones, this is automatically and silently denied. However, the Superuser app can hook into these requests and let any app switch to the "root" user, from which they have full administrative access. A friendly dialog box will pop up, asking you if you want to give the app full permissions. Say yes, and there you go!
A phone in which the Superuser app is running properly is rooted.
Summary: Rooting Methods
The rooting instructions you find will likely be one of these, or a combination of these steps:
Phones with boot loaders that can be unlocked (such as Google's Nexus) will let you flash other partitions. You can flash a whole Android ROM that is already rooted, such as CynaogenMod, and you're done! Or, if you don't want to replace your entire Android ROM, you can flash ClockworkMod into the Recovery partition, and move from there to the next method.
Some rooting methods start with a hacked way to flash ClockworkMod into the Recovery partition. With ClockworkMod, you can run your own special "upgrade" from the SD card. This "upgrade" will vary a lot per phone model, but at the minimum it will involve installing the Superuser app. For some phones, it will modify a few Linux configuration settings to make sure that Superuser app can login as "root." Other, more heavily locked-down phone models might require replacing certain locked parts of Linux and the Android system, sometimes much of the Linux "kernel" itself.
Other rooting methods use the phone's existing Recovery program, but the hackers found a way to create an "upgrade" that can fool the Recovery program into believing it's official. From there on, it's identical to the previous step.
Some rooting methods start straight from Android. Hackers found a way to login as root while Android is running. Of course, logging in as root is not the same rooting, but once you are logged in as root you can run a similar "upgrade" as is used in the previous steps.
Need More Help?
Don't ask me, please! Seriously, I spent a lot of time writing this long article specifically so I would not have to keep answering questions about the process. There are many internet forums and bloggers that welcome questions from noobs. I've generally found the Android hacker community to be extremely generous and welcoming.
Happy rooting!
Nice - but clarification requested
I like the article as it answers some questions.
One thing I'm curious about - you seem to use the terms Recovery Partition and Recovery Program interchangeably. Is that your intent? I'm not trying to split hairs - I just want to understand. I would have expected booting into the recovery partition loads the recovery program.
Also, you talk about how vendors choose features of their recovery program. CWM is then a replacement for the vendor supplied recovery program, correct? If you root then install CWM, are you in effect replacing the recovery program after rooting (as opposed to forcing CWM to overwrite the existing recovery program via flash)?
Thx
Thanks!
A very useful guide for android beginners like me!
Sorry for the bump . This post deserves a thanks and a bump
Thanks! A very useful guide for beginner. I've forwarded this to my colleague who just switched from Windows to Android phone.
Much appreciation!
Thank you so much. I have just purchased a rooted phone & have a ton of questions. Have spent hours here tonight searching for basic info. Finally found this & it really helped this total "noob".
Thank you again.
thanks (very2 usefull) from iphone4 user
Good work..
Sent from my Galaxy Mini using xda-premium
Thanks. It helped very much
how to root sony xperia u
How to root sony xperia U..?
please give me detailed and simple procedure to follow...
i would also happy to know should i have pc drivers to run this rooting process..?
thanks
Thx for taking the time to write the article helped me understand a lot of things
Seeing all the work being done over in the dev section, I was reminded of something I did when modding my xbox. The boot img for the xbox is very small, it basically just looks for various executable files in order from different places and then fails if it doesn't find them..and that's all it does, so it is much smaller than an entire ROM, 256k to be exact. The thing is the chip it was contained on in earlier models of the xbox were 1MB, 4 times what was needed. By shorting out the board on the TSOP one could use a physical switch to toggle how much of the chip was visible to the CPU, and you could in essence split this chip into four banks, and flash 4 different boot images if you wanted (although you needed a 4 position switch and a hell of a lot of 32 gauge wire + patience). Since that was really overkill, what I did was split the TSOP into 2 banks and flashed 2 separate bootloaders, one could remain stable and near stock, as to maintain all the function of the xbox, while with a flick of the switch I could boot from and flash the other bank experimentally, if it failed to flash or got stuck in a bootloop then you could switch over and reflash from the working side, keeping it from being brickable.
Now, of course we have much more control over a rooted android device's hardware via software than the xbox has, and can dual boot without adding switches and soldering the board (at least in the case of ubuntu), I was wondering is there any way to get a Eee Pad dual-booting from two ANDROID partitions, so one could boot and flash developing roms (like the ICS rom coming along in the dev section) while maintaining a safe bootable img that works as a safeguard?
Or does hardware limit this function in our machines?
It may be possible to do so by installing one of the ROMs to the recovery partition like we can do with Ubuntu.
I'm sure something like Boot Manager, that stores ROMs on the SD card, could be put in place for dual booting.
Sent from my Transformer TF101 using XDA App
Does recovery boot from the internal SD card or does it flash to an internal EEPROM chip?
I know the ROM itself is on the SDcard internally like any OS, wondering if there might be a way of getting the bootloader to actually search for a file on the external SD card and if it doesn't find it search for the same sys file that the OS uses on the internal?
On the xbox, the OS file was initiated by launching a single file, named default.xbe (xbe=xbox executable files), and all autorun files on the discs were also named 'default.xbe'..is this an option to actually change the initialization of the bootloader to search for the OS on the external before trying to boot from the internal OR conversely simply partitioning the interanl (though I don't know how you would go about getting the bootloader to differentiate between one partition and the other, much less have control of which it chooses to load/flash, without perhaps an intermediate 'OS selection' option)
this is not an xbox.
EDIT: however there would be a way to boot 2 android partitions, it would just require a very different set up to what you are saying. you are stuck in the minimalist xbox approach that has a small microkernel which can only run one executable at a time
I know it isn't an xbox, but that is the only linux-based system I've got experience hardware modding, I assume the TF could assume a similar function without hardware modifications..?
On another note- I just found out that there is an Android PS3 emulator (WOW) wondering how far off an Xbox360 emulator is from being ported from PC to Android..that would give someone a reason to want to dual boot...would be a novel thing to turn on the TF and be greeted by a gaming console boot animation
luna_c666 said:
I know it isn't an xbox, but that is the only linux-based system I've got experience hardware modding, I assume the TF could assume a similar function without hardware modifications..?
On another note- I just found out that there is an Android PS3 emulator (WOW) wondering how far off an Xbox360 emulator is from being ported from PC to Android..that would give someone a reason to want to dual boot...would be a novel thing to turn on the TF and be greeted by a gaming console boot animation
Click to expand...
Click to collapse
lol, xbox is winnt based not linux based
I understood it was UNIX based, at least the EVOX and UNLEASHX dashboards were, I wrote code for them and had to study UNIX in order to do so..I'm sure the OEM xbox stuff was MS proprietary, but everyone went to UNIX based dashboards instead, even installing DSL (Damn Small Linux). I even got a ported version of Windows CT running in a Linux application on the OEM Xbox, but now we are getting way off topic- my knowledge (or lack thereof) of the xbox isn't what's in question, rather my desire to learn MORE about the TF..how about giving me some constructive information instead of simply trying to tell me I am wrong here?
ok yes, we are getting away from the point, as I said, yes it could be done but not quite in the way you propose, it is a fair bit of work.
Check out the ubuntu project for android,
It creates two partitions by using your recovery area.
But the end result is that you a boot android or b boot ubuntu arm. (Don't get excited with arm ubuntu 90% of what I wanted to do I couldn't since its arm.
But my point is, I bet that could be easily modified replacing the ubuntu image with another android image and maybe some other stuff to "dual boot" your tf101.
Course the more I think about it the more reasons I get to doubt it'd be that simple.
Idea 2, one word..... safestrap.
Sent from my XT862
Ok ignore half of what I said, coffee hasn't kicked in and I didn't the part where you mention the Ubuntu project.
So my vote is going to a safestrap. Its exactly what I do on my Droid 3. Non safe is my rooted debloated ROM. Reboot, enable safe mode and I get hashes ics ROM.
Although this use isn't what he designed it for, it's a useful side effect. Takes about 3 minutes to get from nonsafe to safe, for me.
Sent from my XT862
I will have to look up safestrap I've never heard of it, is it a hardware device?
luna_c666 said:
Seeing all the work being done over in the dev section, I was reminded of something I did when modding my xbox. The boot img for the xbox is very small, it basically just looks for various executable files in order from different places and then fails if it doesn't find them..and that's all it does, so it is much smaller than an entire ROM, 256k to be exact. The thing is the chip it was contained on in earlier models of the xbox were 1MB, 4 times what was needed. By shorting out the board on the TSOP one could use a physical switch to toggle how much of the chip was visible to the CPU, and you could in essence split this chip into four banks, and flash 4 different boot images if you wanted (although you needed a 4 position switch and a hell of a lot of 32 gauge wire + patience). Since that was really overkill, what I did was split the TSOP into 2 banks and flashed 2 separate bootloaders, one could remain stable and near stock, as to maintain all the function of the xbox, while with a flick of the switch I could boot from and flash the other bank experimentally, if it failed to flash or got stuck in a bootloop then you could switch over and reflash from the working side, keeping it from being brickable.
Now, of course we have much more control over a rooted android device's hardware via software than the xbox has, and can dual boot without adding switches and soldering the board (at least in the case of ubuntu), I was wondering is there any way to get a Eee Pad dual-booting from two ANDROID partitions, so one could boot and flash developing roms (like the ICS rom coming along in the dev section) while maintaining a safe bootable img that works as a safeguard?
Or does hardware limit this function in our machines?
Click to expand...
Click to collapse
Couldnt you mount the developing or experimental ROM's like ics as loop devices?
Im not sure how many loop devices you can have but i think its like 6 or something
Before little stevie brought out hes ubuntu system thats how i had linux for awhile it wasnt the fastest or most efficient but good enough for testing
Sent from my tf Enigmatic V2 beta 1.65Ghz Panda.test cust kernel settings
Hello!
I run a computer repair company up in Northern Canada, and I get about 3-5 Android devices a day which are mostly requiring screen repairs.
As part of our policies here with desktop/laptop computers and Mac based systems, before any work is done we clone the OS Drive of the machine for a backup in case of catastrophic failure (which happens more often than you think). We keep these backups for 30 days.
We already do this with iTunes for all IOS devices that come in, however I'd like to run this sort of system with the Android devices that come in. The devices will range from older KK based off brand devices, up to the latest Samsung/Sony/LG/HTC (etc.) devices and everything in between.
Is there a way to clone the whole phone so I can restore it to a new device of the same model in the event that the device is broken? I know TWRP will do this with the MD5 verification turned off (as I'd like to store these backups on a computer drive or external drive) but to install/flash TWRP on every device that comes in here would be warranty voiding (maybe?), against some customers wishes, and also time consuming.
Ideally I'd like to have a way to do this with a PC that I can just "Back up". No root or Xposed modules please, as that also can follow the same problems coming with TWRP installs mentioned above.
To recap:
1. Clone multiple different Android devices from KK to MM, and store the backups (or be moveable) to a PC. If I require multiple programs (Samsung Kies with Sony PC Companion, etc. that's fine, however I'm looking for an all-in-one.
2. Allow above backups to be restored to same model but different serial numbered devices (in the event we need to buy another "Galaxy S7" because the first one is bricked).
3. Program and devices must not require Xposed, TWRP, Root, or similar. I can't modify the devices that come in for warranty reasons.
Possible?
Wiltron said:
Hello!
I run a computer repair company up in Northern Canada, and I get about 3-5 Android devices a day which are mostly requiring screen repairs.
As part of our policies here with desktop/laptop computers and Mac based systems, before any work is done we clone the OS Drive of the machine for a backup in case of catastrophic failure (which happens more often than you think). We keep these backups for 30 days.
We already do this with iTunes for all IOS devices that come in, however I'd like to run this sort of system with the Android devices that come in. The devices will range from older KK based off brand devices, up to the latest Samsung/Sony/LG/HTC (etc.) devices and everything in between.
Is there a way to clone the whole phone so I can restore it to a new device of the same model in the event that the device is broken? I know TWRP will do this with the MD5 verification turned off (as I'd like to store these backups on a computer drive or external drive) but to install/flash TWRP on every device that comes in here would be warranty voiding (maybe?), against some customers wishes, and also time consuming.
Ideally I'd like to have a way to do this with a PC that I can just "Back up". No root or Xposed modules please, as that also can follow the same problems coming with TWRP installs mentioned above.
To recap:
1. Clone multiple different Android devices from KK to MM, and store the backups (or be moveable) to a PC. If I require multiple programs (Samsung Kies with Sony PC Companion, etc. that's fine, however I'm looking for an all-in-one.
2. Allow above backups to be restored to same model but different serial numbered devices (in the event we need to buy another "Galaxy S7" because the first one is bricked).
3. Program and devices must not require Xposed, TWRP, Root, or similar. I can't modify the devices that come in for warranty reasons.
Possible?
Click to expand...
Click to collapse
Greetings,
Please read the description and Sticky threads for XDA Assist. We are not a help desk. Our purpose here, is to aid NEW members in finding the correct forum or thread for their issues. You, being a Senior member, are expected to use the search features provided to you to find the best place to post your question. Nothing personal, we just don't help Senior members here.
Thanks for understanding and good luck with your query.
Thread closed.