Database Develop

[BOOTLOADER BYPASS -WIP] EternityProject Kexec method for Motorola Olympus (Atrix 4G)

Welcome to Eternity Project!
So... as most of you know I'm working on the Atrix solution from TOO MUCH time.
With the collaboration of people on #moto-atrix I've stated that FUSES on Tegra2 are really OTP, so there isn't any way to CRACK the BL, but we can still BYPASS it.
So... what is it?:
kexec is a "fastreboot" that won't pass through the Moto Bootloader, so with it it's possible to use custom kernels and, with some other development, custom Android systems like CM7 and many others.
Where's the poop?
Okay, that's it: I've successfully compiled and ran kexec on the Atrix 4G, so that kexec works, but it needs a kernel that can boot with kexec. On x86 we can build a relocatable kernel so no problems... but not on ARM and obviously not on Tegra.
The thing that is missing is exactly... _the address of the boot params_!
And now?
I'm only searching for help for completing the project and make a kernel that is bootable from my god-it-is-really-working-kexec. Any devs around?
Downloads:
- Kexec pack V0.01: DOWNLOAD
Kexec pack contains:
- ATAGS for MB860 (ATRIX_atags.tar)
- ATAGS hack module (eternity_procfs.tar)
- kexec module (eternity_kexec.tar)
- kexec tools/binaries (kexec-tools.tar)
- Kernel....that doesn't work. (eternity_kexec_kernel.tar)
So, what does work and what does not?
- ATAGS hacky hack: WORKING
- kexec module: WORKING
- kexec tools/binaries WORKING
- Kernel ToDo
How to run it:
0. FLASH AT&T 1.2.6 SBF PRIOR DOING ANYTHING
1. Extract all the archives
2. Insert the procfs_rw.ko module
3. cat atags > /proc/atags
4. Insert the kexec module
5. Run kexec for loading the kernel and jumping to it.
6. Boot! :|
P.S.: I won't release detailed how-tos because at this state I only need a DEVELOPER that can help me to build the kernel.
Thanks to:
- PAulyHoffman (special thanks!)
- unknown
- Sogarth
- the2dcour
- cranch
- eval-
- and many, many others....!

Awesome, i can verify that this kexec is working and will continue testing until we succeed.

random boot animation I made for eternity project
http://diamantephoto.com/bootanimation_red.zip
Also: 1.2.6 without losing /data, in case you were wondering exactly why I made this
http://forum.xda-developers.com/showthread.php?t=1073439

kexec pack updated. now kexec-tools is included

@kholk: Hai;
so basically this is a port of the unix kexec to run on tegra based devices?
From my understanding the android system uses a boot image that has the ramdisk and kernel combined together and they are dependent on each other... so won't overwriting the kernel at runtime give you us some issues since the core initialization of the system is ran from the ramdisk???
wouldn't be a better idea to tackle this issue too? but then again the only reason we can't flash boot images is because of the bootloader but ofcourse this is definitely a step forward for the tegra users.
now about the kernel, theoretically if we build an aosp tegra kernel from http://android.git.kernel.org/?p=kernel/tegra.git;a=summary shouldn't it work?
I can try building us a kernel if that would work
PS: people let's keep this dev ONLY if you want us to get some progress we need able to read through the thread without useless posts.
edit: also found this https://opensource.motorola.com/sf/frs/do/listReleases/projects.atrix/frs.olympus I'm sure having the source for the kernel we are currently running is also helpful

I know we should keep this dev only but please don't tell me this is for ATT only i already feel shafted enough being a Bell user and that would make it a hell of a lot worse if it was

Ratchet556 said:
I know we should keep this dev only but please don't tell me this is for ATT only i already feel shafted enough being a Bell user and that would make it a hell of a lot worse if it was
Click to expand...
Click to collapse
When a kernel that works will be deployed I'll personally port it to Bell Atrix. This will take only some seconds.

kholk, perhaps we can ask a defy developer (or any of the phones that have kexec working) to help us build the kernel.
it's too bad da_g isn't around, he did a custom kernel but wasn't able to boot it.

I'm not a developer so I am hoping someone can help me understand this process better. From my understanding kexec is used as a reboot method that skips initial bootloader and hardware loading so how will this effect if we turn our phone off or pull the battery? Will the device need to be rebooted after initial startup to reactivate the kexec? Sorry to sound like the newbie that I am, I'm just interested in learning more.

lostinbeta said:
I'm not a developer so I am hoping someone can help me understand this process better. From my understanding kexec is used as a reboot method that skips initial bootloader and hardware loading so how will this effect if we turn our phone off or pull the battery? Will the device need to be rebooted after initial startup to reactivate the kexec? Sorry to sound like the newbie that I am, I'm just interested in learning more.
Click to expand...
Click to collapse
Yeah, I'm also a little confused as to what exactly this means for all of us people who want to just flash Custom ROMs and such? In what ways is this different than just an unlocked bootloader and such?

lostinbeta said:
I'm not a developer so I am hoping someone can help me understand this process better. From my understanding kexec is used as a reboot method that skips initial bootloader and hardware loading so how will this effect if we turn our phone off or pull the battery? Will the device need to be rebooted after initial startup to reactivate the kexec? Sorry to sound like the newbie that I am, I'm just interested in learning more.
Click to expand...
Click to collapse
thebeardedchild said:
Yeah, I'm also a little confused as to what exactly this means for all of us people who want to just flash Custom ROMs and such? In what ways is this different than just an unlocked bootloader and such?
Click to expand...
Click to collapse
Assuming my understanding of kexec is correct, this would survive battery pulls. Basically, a custom rom would need to include two kernels: a Motorola kernel in addition to the custom one. The bootloader would run the Motorola kernel, which should pass any checks the bootloader would make. From there, the kernel would use kexec to load the custom kernel over itself in memory, effectively replacing itself. From there the custom kernel can continue loading the rom.
If the booloader were unlocked, the phone could directly boot the custom kernel. The downside of loading the custom one on top of the Motorola one is that the state of the phone might not be entirely known, so it would need to do more work checking what's been initialized and what hasn't. Its a little more work for the kernel/rom developer, but the end result is the same.

Jotokun said:
Assuming my understanding of kexec is correct, this would survive battery pulls. Basically, a custom rom would need to include two kernels: a Motorola kernel in addition to the custom one. The bootloader would run the Motorola kernel, which should pass any checks the bootloader would make. From there, the kernel would use kexec to load the custom kernel over itself in memory, effectively replacing itself. From there the custom kernel can continue loading the rom.
If the booloader were unlocked, the phone could directly boot the custom kernel. The downside of loading the custom one on top of the Motorola one is that the state of the phone might not be entirely known, so it would need to do more work checking what's been initialized and what hasn't. Its a little more work for the kernel/rom developer, but the end result is the same.
Click to expand...
Click to collapse
I see, thanks for the explanation! So, on the user end, would there be any noticeable differences? This kind of makes it sound like the phone will be doing a lot more work, so could we see performance decrease or perhaps startup lag or something of the sort? Or would this all pretty much function on the surface as if we had flashed a custom ROM on some phone without a locked bootloader?

thebeardedchild said:
I see, thanks for the explanation! So, on the user end, would there be any noticeable differences? This kind of makes it sound like the phone will be doing a lot more work, so could we see performance decrease or perhaps startup lag or something of the sort? Or would this all pretty much function on the surface as if we had flashed a custom ROM on some phone without a locked bootloader?
Click to expand...
Click to collapse
Boot time will be about twice as long. Other then that, everything will run about the same

Yes thank you very much for that explanation... though I do also have the question about stability. By replacing the current kernel in memory with the new modified kernel the phone state may get confused as you mentioned... could this cause instability as a whole or increase risk of kernel panics? Or once everything is loaded and complete does it stabilize with the modified kernel?
Again sorry for the questions. This topic intrigues me and I love learning how stuff works.

thebeardedchild said:
I see, thanks for the explanation! So, on the user end, would there be any noticeable differences? This kind of makes it sound like the phone will be doing a lot more work, so could we see performance decrease or perhaps startup lag or something of the sort? Or would this all pretty much function on the surface as if we had flashed a custom ROM on some phone without a locked bootloader?
Click to expand...
Click to collapse
Only difference would be that it might take slightly longer to boot up. Once the phone is finished booting, there's no difference in terms of performance because by that point the Motorola kernel isnt running, or even loaded.

thebeardedchild said:
Haha yeah I'm checking every like 2 seconds now. What exactly do we wait for then? Someone to just create the custom kernel, and then of course wait for some Custom ROMs to be created? I hope we get CM7!
Click to expand...
Click to collapse
Kexec isn't fully operational yet, still need to find boot params. Then custom kernel.

How easy will this be to install on our phones? will it just be something we need to flash through CWM or will it require some more work then that to install?

Ratchet556 said:
How easy will this be to install on our phones? will it just be something we need to flash through CWM or will it require some more work then that to install?
Click to expand...
Click to collapse
I imagine some of the preliminary stuff may need to be pushed with ADB but devs are always nice and give us very clear guides. And I'm sure either a dev or active member could easily create a batch script.
Even though I'm comfortable with ADB I always make scripts for myself because I regularly wipe me phone and whatnot. Because it's so engaging some people might want to wait until a few normal community members test this out so we can see if there are any glaring challenges with the instructions. Just remember to back things up, read instructions clearly and I'm sure we'll all be fine. We've got SBFs and all that good stuff to cover our asses too.

Would it be possible to bring fastboot off the htc to this? Then we won't have to worry about boot time at all. Even if it did double the boot time...
Sent from my MB860 using XDA App

PixoNova said:
This bypasses the bootloader
Swyped from my Motorola Atrix 4g using XDA Premium App
Click to expand...
Click to collapse
Correct this method has nothing to do with unlocking the bootloader and previous attempts at that proved it maybe impossible.

[Q] A multitude of questions

Hi everyone. I'm the proud owner of a new Droid 3, and I have some questions about ROMs and stuff that I'm hoping someone can answer:
1. As I understand, the Droid 3's bootloader is locked. As I understand it, the /boot partition is signed and we can't modify it, right? Are any other partitions signed this way? What about any kind of encryption or something on the partitions? I read somewhere that certain Motorola phones with OMAP chipsets have encrypted stuff. Is the Droid 3 one of these devices? If so, what is encrypted?
2. What ways around whatever verification on the device exist? Is 2nd-init a technique used on this device, like on the Droid 2 and other Motorola phones?
3. As I understand it, SafeStrap boots the phone from /preinstall, not system, and leaves /system intact when flashing stuff. Is this correct? What's the point? Every other Android device I've used doesn't have anything like that (afaik). And why doesn't it do the same for /data?
4. On the topic of SafeStrap, if I wanna dual boot Motoblur and Cyanogenmod, can I? (I know this is possible on the Bionic, so I'm assuming the same is true for the Droid 3) How?
5. This phone supports fastboot commands, which is unusual for Motorola devices, right? What would happen if I issued it a "fastbook oem unlock" command?
6. What is "BP," as in "BP Tools?"
Thanks a ton
-Zane

ZaneKaminski said:
Hi everyone. I'm the proud owner of a new Droid 3, and I have some questions about ROMs and stuff that I'm hoping someone can answer:
1. As I understand, the Droid 3's bootloader is locked. As I understand it, the /boot partition is signed and we can't modify it, right? Are any other partitions signed this way? What about any kind of encryption or something on the partitions? I read somewhere that certain Motorola phones with OMAP chipsets have encrypted stuff. Is the Droid 3 one of these devices? If so, what is encrypted?
2. What ways around whatever verification on the device exist? Is 2nd-init a technique used on this device, like on the Droid 2 and other Motorola phones?
3. As I understand it, SafeStrap boots the phone from /preinstall, not system, and leaves /system intact when flashing stuff. Is this correct? What's the point? Every other Android device I've used doesn't have anything like that (afaik). And why doesn't it do the same for /data?
4. On the topic of SafeStrap, if I wanna dual boot Motoblur and Cyanogenmod, can I? (I know this is possible on the Bionic, so I'm assuming the same is true for the Droid 3) How?
5. This phone supports fastboot commands, which is unusual for Motorola devices, right? What would happen if I issued it a "fastbook oem unlock" command?
6. What is "BP," as in "BP Tools?"
Thanks a ton
-Zane
Click to expand...
Click to collapse
Hi Zane,
1. Yes, the bootloader is locked. And more than just the boot partition are signed. Recovery, System and a few others as well. I don't know about encryption support for the OMAP chipsets, but I do know that the chips can enforce the signatures and md5 type verification of partitions. I'm not sure that the Droid 3 is actually making use of this feature. I believe the signature is currently stored in a table on the cdt.bin partition. Several people have tried to edit that partition by hand, erasing the check for signatures on certain partitions and none have been successful.
2. For custom AOSP ROMs we are using a logwrapper hijack to 2nd-init the Droid 3 just like the D2.
3. You are correct. Safestrap uses the /preinstall partition as a 2nd-system. And I'm not sure why it's never been done before, but the idea behind Safestrap is fairly simple:
3a. How do we protect our ability to enter recovery (even after flashing system) when in almost all cases any system flash will over-write the hijack needed to enter recovery in the first place? Flashing a ROM on a locked phone is a touchy issue. And I can't count the # of "I'm bootlooped" or "I'm bricked" posts that you see on these boards because of that. This isn't the case with unlocked bootloaders. They ALWAYS have access to recovery and have a way out. And that makes flashing ROMs alot more fun.
3b. Enter Safestrap which is essentially a 2nd-system Bootstrap. It does the hijack to provide access to recovery and custom ROM booting. The ROMs don't have to worry about it. Safestrap is still in very early stages. The interface isn't as easy as it should be to use. I'll work on that as I get more time.
3c. You bring up a good point about "data". MotoBlur and CM7 have very different sets of userdata, and in some ways they're incompaible. Moto likes to throw security information on the /data partition in various spots and CM7 obviously doesn't do that. I have actually hung at the boot when swapping systems and not changing my user data around. I know there's a video of Deodexed doing this exact thing on his Bionic, but in most cases you can't just "flip the switch" on 2nd-system and boot up correctly. Currently, in Safestrap you need to backup your current ROM's data and then restore/wipe the data you want for the new ROM your going to. This process is time consuming and will be ironed out with the next release. It will perform a mini system-specific backup/restore of just userdata when you enable/disable the 2nd-system. I would have stuck the 2nd-system data on another partition ... if we had another spare one to use.
4. This is the current "default" setup for Safestrap. MotoBlur on the primary system and people are testing CM7 on the 2nd-system. You can download the files here:
http://hash-of-codes.blogspot.com/2011/10/beta-testing-safestrap-w-cm7.html
5. The fastboot oem unlock command doesn't work. Been tried.
6. BP = Baseband Processor. "BP-Tools mode" is special boot mode which opens access to the BP via Motorola Software and a USB cord. Most will never use it.
EDIT: Sorry for the wall of text.. good questions.

-delete- realized Hashcode gave a far better response that I could even dream up.
Sent from my DROID3 using xda premium

That was the best answer to any question (or, well, a bunch of questions) I've read in a long time. Thanks so much.
-Zane

jjhiza said:
-delete- realized Hashcode gave a far better response that I could even dream up.
Sent from my DROID3 using xda premium
Click to expand...
Click to collapse
Such good questions and such a good response are worthy of a sticky/faq imo

[Q] ICS Update for Nexus One

Hi,
My Nexus One details are as follows:
Model number : Nexus One
Android version : 2.3.4
Baseband version : 32.50.00.32U_5.12.00.08
Kernel version : 2.6.35.7-ge0fb012
[email protected] #1
Build number : GRJ22
Which is the best way for me to update my phone to ICS (Android 4.0). I have read the official message from Google on categorizing Nexus One as "old" and will no more air the updates.
I am not familiar with the MODs and so; eventhough I scanned through the ROM section; I couldn't figure out myself which way should I opt to upgrade my phone.
Thanks to all for reading my request as it might be a thousandth time such a request is coming through. Thanks for your patience and your advise is eagerly awaited.
Jabir
PS: I have never done a "jailbreak" or "rooting" (whatever name is it) on my phone except those Google aired updates.

You are going to have to root--no way around it
I did it the old fashion way and installed sdk/fastboot oem unlock/flash recovery and a rom with super user in it or flash super user
instructions are in Wiki
there are different ways now I am not familiar with, but prefer the sdk method
you will also need to be on hboot 35.0017 to install blasckrose, although some ICS roms have a miniversion that can run on stock hboot
However, I would root and flash some roms like CM7 stable to get use to things. The hboot and ICS is a bit more complicated at first--read the threads carefully before attempting

Start reading.
http://forum.xda-developers.com/showthread.php?t=1366897

ursJAR said:
Hi,
My Nexus One details are as follows:
Model number : Nexus One
Android version : 2.3.4
Baseband version : 32.50.00.32U_5.12.00.08
Kernel version : 2.6.35.7-ge0fb012
[email protected] #1
Build number : GRJ22
Which is the best way for me to update my phone to ICS (Android 4.0). I have read the official message from Google on categorizing Nexus One as "old" and will no more air the updates.
I am not familiar with the MODs and so; eventhough I scanned through the ROM section; I couldn't figure out myself which way should I opt to upgrade my phone.
Thanks to all for reading my request as it might be a thousandth time such a request is coming through. Thanks for your patience and your advise is eagerly awaited.
Jabir
PS: I have never done a "jailbreak" or "rooting" (whatever name is it) on my phone except those Google aired updates.
Click to expand...
Click to collapse
0. Set up ADB correctly.
1. Root.
2. Optional: Unlock the bootloader
3. Optional: Set SecuFlag off, i.e. S-OFF
4. Fastboot flash a custom recovery
5. Fastboot flash blackrose's hboot. Either stock blackrose or the one specifically for ICS (custom partition layout)
6. Download an ICS ROM of your choosing. My pick would be texasice's.
7. Download an A2SD script as the default one is a li'l buggy.
8. Boot into the recovery of your choosing (4EXT or AmonRa preferred)
9. Make a FULL wipe of settings and partitions and wipe cache and dalvik cache.
10. Flash the ROM zip file
11. Flash the A2SD script file
12. Reboot and boot up your phone. Enter a terminal emulator. Type: su
13. Accept the root request and then type a2sd install,
14. Let your phone reboot on its own and then boot it up again,
15. Return to the terminal emulator, type su and then a2sd cachesd and let it reboot once more.
16. Now you're good to go.
Find out all info on your own, I simply tell you what you need to do.

Theshawty said:
0. Set up ADB correctly.
1. Root.
2. Optional: Unlock the bootloader
3. Optional: Set SecuFlag off, i.e. S-OFF
4. Fastboot flash a custom recovery
Click to expand...
Click to collapse
If you are going to be using fastboot to flash a custom recovery, root is not needed and unlocking the bootloader is not Optional. Root is only needed if you are going to flash the recovery through Android with a program like ROM Manager. Also, S-Off also is something we can't officially get with our phones without using the XTC Clip. But for pretty much all things that we need to do with our phones, S-Off is not required due to it being a dev phone.

As a matter of fact, unlocking the bootloader is actually completely optional, and unless you are doing hardcore modding, completely unnecessary - not to mention that it is the definitive method to losing your warranty. Root, on the other hand, is completely reversible and virtually undetectable if you restore to a stock ROM if you ever need warranty service.
I only started modding recently (a month ago) and in that time, I've already moved to ICS and using a custom Blackrose HBOOT. Its fairly easy - you just have to have the ability to read patiently.
Here is what I would advise, being a bit of a noob myself - yet having never had a single hiccup. This is pretty much the fastest way to do it.
1. Enable USB debugging (in settings>applications>development)
2. Download SuperOneClick (Google it, also has USB drivers if necessary)
3. Connect your phone to the computer, and once all drivers are installed, fire up SuperOneClick, hit 'Root' and watch the magic unfold
4. Download ROM Manager from the Market, follow the instructions (Flash recovery>Download a ROM (CM7 recommended))
Once you are familiar with the basics of installing a ROM from ZIP, head over to the Dev forums, and download ICS for stock HBOOT to get you started!

mrhohoha said:
As a matter of fact, unlocking the bootloader is actually completely optional, and unless you are doing hardcore modding, completely unnecessary - not to mention that it is the definitive method to losing your warranty. Root, on the other hand, is completely reversible and virtually undetectable if you restore to a stock ROM if you ever need warranty service.
Click to expand...
Click to collapse
This is true. I was just going off the instructions that Theshawty wrote. In the instructions he included directions to use fastboot. And without replacing the bootloader to Blackrose (which is probably too in depth to do include here), using fastboot would require the bootloader to be unlocked.

bassmadrigal said:
If you are going to be using fastboot to flash a custom recovery, root is not needed and unlocking the bootloader is not Optional. Root is only needed if you are going to flash the recovery through Android with a program like ROM Manager. Also, S-Off also is something we can't officially get with our phones without using the XTC Clip. But for pretty much all things that we need to do with our phones, S-Off is not required due to it being a dev phone.
Click to expand...
Click to collapse
I have S-OFF'd my device and I didn't use anything called XTC Clip?

Yep. Nothing special required for S-OFF. Heck, you can S-OFF in like 20 seconds by just installing Blackrose! And revert to stock S-ON HBOOT whenever you like!

Using Blackrose does not actually make your device S-Off. The upgraded HBOOT just ignores the flag that is set saying the S-On is still there and displays that you are S-Off. And so, essentially you have S-Off when you use blackrose, but that is only because blackrose ignores the actual setting saying the S-On is still in place. The one thing this will not allow is relocking the bootloader, which full S-Off, when acheived with the XTC Clip, will do.

mrhohoha said:
As a matter of fact, unlocking the bootloader is actually completely optional, and unless you are doing hardcore modding, completely unnecessary - not to mention that it is the definitive method to losing your warranty. Root, on the other hand, is completely reversible and virtually undetectable if you restore to a stock ROM if you ever need warranty service.
I only started modding recently (a month ago) and in that time, I've already moved to ICS and using a custom Blackrose HBOOT. Its fairly easy - you just have to have the ability to read patiently.
Here is what I would advise, being a bit of a noob myself - yet having never had a single hiccup. This is pretty much the fastest way to do it.
1. Enable USB debugging (in settings>applications>development)
2. Download SuperOneClick (Google it, also has USB drivers if necessary)
3. Connect your phone to the computer, and once all drivers are installed, fire up SuperOneClick, hit 'Root' and watch the magic unfold
4. Download ROM Manager from the Market, follow the instructions (Flash recovery>Download a ROM (CM7 recommended))
Once you are familiar with the basics of installing a ROM from ZIP, head over to the Dev forums, and download ICS for stock HBOOT to get you started!
Click to expand...
Click to collapse
The SuperOneClick Application just gets not responding when I click the Root button and after these messages on the right pane are shown
* daemon not running . starting it now on port 5037 *
* daemon started successfully *
Please advise..

Make sure you run it with administrator rights (right click to see the option), and verify that USB Debugging is turned on on the phone. If it is turned on, you need to make sure you have the adb drivers installed (different than the standard USB drivers that windows automatically installs).

Hi all. I have read quite a few pages of the s off blacks install guide. Not really getting it. Can someone please give me simple steps to install blackrose?
Please and thank you.
Sent from my Nexus One using xda premium

Blackrose install guide
Sent from my Nexus One using xda premium

hardrockinandroid said:
Blackrose install guide
Sent from my Nexus One using xda premium
Click to expand...
Click to collapse
Black rose thread http://forum.xda-developers.com/showthread.php?t=1270589

I've read that and everything sounds so complicated. I've watched the vid for resizing partition but they don't say anything. Can someone give a step by step for us noobs for resizing partition please?
Sent from my Nexus One using xda premium

do you have all requirements met from br op page
if so, you need to download the latest br from op and extract it to the download folder you just downloaded br to. then open the extracted folder and clickon br.exe
follow instructions inside the command window that opens
then you need to resize partition to ics sizes thru the breditor

What is op page?Yes bootloader unlocked. Rooted. I have the blackrose zip.the adb and fastboot drivers for windows. Don't know what to do now. I put both files on my desktop. Now what?
Sent from my Nexus One using xda premium

OP page is first page of Dev's thread--mmm
Needs read as well as most of thread to get an understanding of this--lots of folks are running into big trouble if they don't understand it first--
If you are rooted and unlocked do you have sdk installed and can you run adb devices and fastboot devices in command window and see phone's serial number? If so you don't need the usb drivers from OP page--

Yes I have ran commands on a my touch4g, a HTC sensation and a g 2x. Do I just do exactly as the YouTube video shows and then flash the blackrose zip after resizing
the partition? Then flash an Ics Rom?
Sent from my Nexus One using xda premium

[PRERLS-REF] Root, BL, Kernel, Recovery

This thread is left here only for historical purposes ! Now that the device has been released, easier and better methods have been developed to gain root, like CF-Root.
.
.
.
.
.
Check your device model ! Settings -> About device -> Model number. This stuff is made for the GT-I9300, if your model number has a suffix, it may not work, or if it is a totally different model, it will not work (may even brick) !
Ladies and gentlemen, we have root on the SGS3 (!)
This will all be common knowledge in the near future, but here's some info I though various devs, chefs, and users will be dying to know!
Unfortunately, I am not able to share the "insecure" kernel with you at the moment, because of fears it is traceable to the leaker (this is said to be the last traceable firmware revision).
Update: The kernel is linked at the bottom of the post.
Update: The easiest way for rooting is now CF-Root
This root is, as expected, trivial. It was a simple matter of repacking the stock kernel, with a modified adbd binary that thinks ro.secure=0 (even if ro.secure=1). This gives access to all adb root commands (see screenshots). Then SuperSU was installed manually.
Kernel
The modification was trivial, because this time around, Samsung is using the standard boot.img format, instead of the zImage format used for SGS1, SGS2, SGNote, etc, that is much harder to repackage.
This is also why I don't feel particularly bad about not giving you the insecure kernel - any serious dev on this board can do the same thing in 10 minutes.
Recovery
The recovery partition is also being used this time around. And thus we can flash recoveries separately from the kernel.
Bootloaders
There was no warning triangle at boot-up after flashing the modified kernel, but download mode did show a custom kernel flash counter which increased. Whether or not flashing a custom recovery also triggers this counter is as of yet unknown. Both flashing kernel and/or flashing recovery will trigger the flash counter!
Final note
This was all tested on a current (release candidate) SGS3 firmware. There may be a newer firmware on true retail/production devices. Though some things may change, it is unlikely to change much. Let's hope nothing
Also, Triangle Away did not work. They have hidden the boot partitions again as on the latest SGNote firmwares.
(No, I don't have an SGS3 yet, everything was done remotely)
Now, everybody say thanks to Samsung! I don't always agree with them, but so far they have been the first and IMHO still are the only high-end Android OEM who aren't complete douchebags in the unlock department!
Download
The instructions below assume some basic knowledge about Samsung devices. This is not a noob-proof guide.
Here's the "insecure" kernel, based on XX NEE ALE8 firmware:
CF-Insecure-SGS3_XX_NEE_ALE8-v1.2.zip
- Extract the linked file (you will get a .tar file)
- Use the ODIN version attached below to that .tar file to your SGS3 as "PDA"
Going from insecure to full root
After having flashed the insecure kernel, boot your phone, and make sure USB debugging is enabled.
Your device is now insecure, so you can use the adb root commands. This does not allow your on-device apps to get superuser access, though. For that, you need to install SuperSU:
Download and extract the sgs3-root-install.zip file, containing SuperSU v0.89. Make sure adb is running correctly, then just double click install.bat (this will reboot your phone).

Wow, that was fast!

Chainfire said:
Ladies and gentlemen, we have root on the SGS3 (!)
(No, I don't have an SGS3 yet, everything was done remotely)
Click to expand...
Click to collapse
bravo my friend i hope the candle wasnt the inspiration or errr turpitude dayyyyymn.....nough said....thanks for leading the way

Appreciate

Finally boot.img/recovery.img about time samsung(on their flasg ship that is)

Remotely! Good work, i can't wait to get the device .
Sent from my GT-I9100 using Tapatalk 2

thats great. i hope they don't 180 on the boot.img format.

So is the GSIII bootloader unlocked from factory or did it require a bootloader unlock?

Phistachio said:
So is the GSIII bootloader unlocked from factory or did it require a bootloader unlock?
Click to expand...
Click to collapse
As with the SGS1, SGS2, and SGNote, it was never locked to begin with.

Awesome!

Awesome work man. Maybe triangle issue can be solved with usb jig

There u go
Sent from my GT-I9100 using Tapatalk 2

Great news!
Can you work any magic with Asus TF300T

Quick work, well done.

Chainfire said:
As with the SGS1, SGS2, and SGNote, it was never locked to begin with.
Click to expand...
Click to collapse
Props to Samsung!

That was fast!
That's 11 days before the device is available commercially! WHoa! That was fast!

W0W. There we meet again. Nice one dude !

I'd be very reserved with yelling "Tjohoo" at this point. Things can change a lot between a developer version (which I assume is the one on Chainfire's hands) and a fully commercial shipper version. Let's just hope Samsung stay cool, and don't cause us more trouble than necessary, like has happened with the HTC One X...

Grats on the fast work man, and even more impressive is that it was done remotely on Windows 8! I've heard a lot of people having issues just getting ADB to work on Windows 8, and yet you managed to root a device for the first time ever using it without even physically having the device!
You truly are an inspiration to this community.
---------- Post added at 02:06 PM ---------- Previous post was at 02:05 PM ----------
E:V:A said:
I'd be very reserved with yelling "Tjohoo" at this point. Things can change a lot between a developer version (which I assume is the one on Chainfire's hands) and a fully commercial shipper version. Let's just hope Samsung stay cool, and don't cause us more trouble than necessary, like has happened with the HTC One X...
Click to expand...
Click to collapse
He doesn't have any device in his hands, that's what makes this even more impressive!

Very nice work, thank you and congratulations!

[WIP] Building CM 10.1

Granted, it has been a while since I've built CM, and never ported it to a new device, but figure this might give some smarter people a head start or at least provide a place for others to collaborate.
I've not gotten very far past the initial vendor setup per http://wiki.cyanogenmod.org/w/Doc:_porting_intro.
A lot of the work is based off the similar ASUS TF700T, https://github.com/CyanogenMod/android_device_asus_tf700t.
I've not messed with the kernel at all at this point, https://github.com/ouya/ouya_1_1-kernel.
I've uploaded everything so far to github, https://github.com/vinny75/android_device_ouya_ouya_1_1

Packages included with official build:
OUYA Framework, Launcher, and Store
Code:
app\OUYAKeyboard.apk
app\OUYALauncher.apk
app\OUYAOOBE.apk
app\OUYAWallpaper.apk
app\ouya-framework.apk
note: some media files I haven't list
CWiid for Android: http://cvpcs.org/projects/android/cwiid4android and https://github.com/cvpcs/android_external_cwiid[.
Code:
bin\wminput
lib\libcwiid.so
etc\acc_led
etc\acc_ptr
etc\buttons
etc\gamepad
etc\ir_ptr
etc\neverball
etc\nunchuk_acc_ptr
etc\nunchuk_stick2btn
Sixpair for PS3 controllers http://www.blog.kaiserapps.com/2012/10/setting-up-sixaxis-controller-android.html.
Code:
/bin/ps3service
/bin/sixpair

I noticed that the recovery.fstab committed is from the Ouya stock recovery partition. When getting cwm to work properly with the internal sdcard, we ended up having to change the sdcard line.
I made the change and submitted a pull request.
Edit: I saw you merged the change.
Sent from my Nexus 7 using xda premium

mybook4 said:
I noticed that the recovery.fstab committed is from the Ouya stock recovery partition. When getting cwm to work properly with the internal sdcard, we ended up having to change the sdcard line.
I made the change and submitted a pull request.
Edit: I saw you merged the change.
Click to expand...
Click to collapse
Thanks, appreciate the help, hopefully, we'll have a working build soonish

If you need any help with kernel debugging/boot issues, I'll be happy to offer up the assistance of my bus pirate.
I was looking at building CM also, but there was always that step in every tut I looked at for "how to port CM to a new device" that basically said "select your device from the build tree"... well if it was in the device tree it wouldn't really be a "new" device then would it!
Also you may want to look at building 10 instead of 10.1, might have less kernel issues as its 4.1.2 jb... at least so we can get some alternative rom working then go for 10.1 after that.
Good luck!

Vinny75,
What method did you use to create the files?
"Method 1: Use mkvendor.sh to generate skeleton files"
"Method 2: Fork a similar device's git repository"
or "Method 3: create the directories and files manually"

mybook4 said:
Vinny75,
What method did you use to create the files?
"Method 1: Use mkvendor.sh to generate skeleton files"
"Method 2: Fork a similar device's git repository"
or "Method 3: create the directories and files manually"
Click to expand...
Click to collapse
I started out with Method 1 then moved over files and settings from the ASUS TF700T.

professorpoptart said:
If you need any help with kernel debugging/boot issues, I'll be happy to offer up the assistance of my bus pirate.
I was looking at building CM also, but there was always that step in every tut I looked at for "how to port CM to a new device" that basically said "select your device from the build tree"... well if it was in the device tree it wouldn't really be a "new" device then would it!
Also you may want to look at building 10 instead of 10.1, might have less kernel issues as its 4.1.2 jb... at least so we can get some alternative rom working then go for 10.1 after that.
Good luck!
Click to expand...
Click to collapse
Yes, building the new device tree has been... uhm... educational... and I am still learning. If I don't make any headway on 10.1, I might drop back to 10 - at least most of the legwork will be done.

Ok, so I'm in the middle of a build
Have a vendor tree on my git and I forked Vinny75's device tree, modified it some
Also a kernel tree up there, which is required for my device tree (prefer to build the kernel myself =) I've booted a custom-built kernel on it already, so that shouldn't be an issue)
I'm nervous to flash this though. I did a bit of searching but couldn't come up with a way to get back into recovery should this thing not boot. You guys know of anything?

Other than using adb to reboot to recovery, http://forums.ouya.tv/discussion/1380/recovery-mode is all I've seen so far to force into recovery mode.
Sent from my Nexus 7 using xda premium

mybook4 said:
Other than using adb to reboot to recovery, http://forums.ouya.tv/discussion/1380/recovery-mode is all I've seen so far to force into recovery mode.
Sent from my Nexus 7 using xda premium
Click to expand...
Click to collapse
Yea, that's what I'm seeing.
So here's my 'solution'
Since we have fastboot, we can boot a boot.img without having to worry about flashing it.
I've successfully booted my cm boot.img, with ro.secure=0 and ro.adb.secure=0, I can adb reboot it when it fails miserably to boot
Quick and dirty script to unsecure a boot.img:
http://pastie.org/8033076
It assume that unpackbootimg and mkbootimg are in your path, you can get them here: http://invisiblek.org/mkbootfs_tools.zip
Getting closer...

THere's a keyboard solution in the Ouya Questions forum in the thread, [Q] Is My Ouya Dead?

dibblebill said:
THere's a keyboard solution in the Ouya Questions forum in the thread, [Q] Is My Ouya Dead?
Click to expand...
Click to collapse
Yeah, I think that is the same solution posted earlier:
mybook4 said:
Other than using adb to reboot to recovery, http://forums.ouya.tv/discussion/1380/recovery-mode is all I've seen so far to force into recovery mode.
Click to expand...
Click to collapse
THis might be another option too:
tylerwhall said:
I started looking into bootloader-level recovery tonight before messing with the file system too much and potentially getting into a bad state. I couldn't find this information anywhere else.
Bootloader strap
On the back of the board in the center, there is an unpopulated button (U33). When jumped while the power button is pressed, this appears to put the bootloader into USB recovery mode. It enumerates with an nvidia vendor id. Presumably nvflash or tegrarcm could be used to unbrick the device.
I haven't done anything with the bootloader recovery since I haven't yet made a backup. I'm not sure how much of the functionality is allowed given the state of the production fuse, but I would think we could use this to at least get back to a stock state.
Click to expand...
Click to collapse

Some NVidia devices lock access out at the nvflash level unless you've got the manufacturer's key. I believe you get locked out with a 0x4 (nvflash's way of saying "go away").
Using fastboot is probably the quickest, easiest, and safest way to test new kernels.
Sent from my SCH-I535 using xda premium

mybook4 said:
Some NVidia devices lock access out at the nvflash level unless you've got the manufacturer's key. I believe you get locked out with a 0x4 (nvflash's way of saying "go away").
Using fastboot is probably the quickest, easiest, and safest way to test new kernels.
Sent from my SCH-I535 using xda premium
Click to expand...
Click to collapse
ah he makes it sound like it puts you in USB recovery mode fo you could ADB in to push an update.

Just wanted to say I'm totally stoked on this guys! Can't wait to see what you do with this. Wish I could help, but I'm really not a developer.

i agree with rebel! but when you guys have it readyish ill test flash it and tell you what happens!!

So, OUYA isn't really as interested in being an open console as they suggest.
I'm keeping a track of how many requests we get relating custom firmware, and from what I'm seeing the user base is not as interested in custom firmware as you might think, which is echoed by this thread (we've shipped 60,000+ units, and less than 10 people have commented in the last month in this thread about getting access to recovery mode).
That doesn't mean that we're shooting the idea down, you need to keep in mind that in terms of priorities this is way down the list as you'd expect from any feature where it's being requested by less than one tenth of one percent of the user-base.
I'm sure @Wajeemba is familiar with CM requests that a very small minority of the user-base are very passionate about, so hopefully you can understand why we're not rushing to work on this.
Click to expand...
Click to collapse
Go to this thread and let them know we want support:
http://forums.ouya.tv/discussion/1380/recovery-mode

That's not even slightly surprising. If every user demanded CM10 they still wouldn't comply, because then they'd lose their one means of profit (ouya store), the fact that "nobody is asking for it" is their excuse, and they'll think of another one if that ever changes.
This is why we just need to proceed without them. I'm on week two of who knows how many weeks away from home on work, so my efforts at porting CM have been put on hold. Have you been able to make any progress? I'd totally loan my Ouya to Fattire or Dalingrin, or another whiz porter if they'd be willing to work on it...

sonofskywalker3 said:
That's not even slightly surprising. If every user demanded CM10 they still wouldn't comply, because then they'd lose their one means of profit (ouya store), the fact that "nobody is asking for it" is their excuse, and they'll think of another one if that ever changes.
This is why we just need to proceed without them. I'm on week two of who knows how many weeks away from home on work, so my efforts at porting CM have been put on hold. Have you been able to make any progress? I'd totally loan my Ouya to Fattire or Dalingrin, or another whiz porter if they'd be willing to work on it...
Click to expand...
Click to collapse
I'd check with invisiblek about how to avoid bricking the OUYA. Apparently his is bricked. It's stuck in nvflash mode. I think it was a kernel written with a bad init.rc that did it. not sure though.
Sent from my Nexus 7 using xda premium