Post Reply

The CWM for Ouya project

OP sonofskywalker3

23rd May 2013, 09:21 PM   |  #1  
sonofskywalker3's Avatar
OP Senior Member
Thanks Meter: 283
 
729 posts
Join Date:Joined: Jan 2009
Donate to Me
Well, since i'm not aware of anyone else doing it, and it will be necessary for any real development to occur, I have decided to try porting Clockworkmod Recovery to the Ouya. I am downloading ubuntu right now and I'll start trying to build it from source against our current recovery tonight or tomorrow night depending on how long the setup and prerequisites take.

The reason I'm posting this now, is to solicit help. I've never built CWM before, but XDA has a really great tutorial I'm going to follow, but if anyone here has had experience in the past I'd love some help/tips, and other than that I would like a few brave souls to volunteer and try flashing it on their Ouya when/if I have a build that works on my own.

I'll update this thread with my progress, if I make any, and please let me know if any of you are willing to help in any way.

Update 1:
I have compiled a version of CWM recovery that theoretically should work, but I'm unable to flash it. I have installed flash_image onto the ouya and it works fine, but i normally would have used "flash_image recovery recovery.img" however there is no "recovery" partition on the ouya. This is what I get:

./flash_image recovery recovery.img
error scanning partitions: No such file or directory

Mount reveals the following info:

mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro,relatime,user_xatt
r,acl,barrier=1,data=ordered 0 0
/dev/block/platform/sdhci-tegra.3/by-name/CAC /cache ext4 rw,nosuid,nodev,noatim
e,errors=panic,user_xattr,acl,barrier=1,journal_as ync_commit,nodelalloc,data=wri
teback 0 0
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 rw,nosuid,nodev,noatime
,errors=panic,user_xattr,acl,barrier=1,journal_asy nc_commit,nodelalloc,data=writ
eback 0 0
/dev/fuse /storage/sdcard0 fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1
023,default_permissions,allow_other 0 0

This is the script from the OTA update:
#!/system/bin/sh
if ! applypatch -c EMMC:/dev/block/platform/sdhci-tegra.3/by-name/SOS:5906432:f80238c4f4a53888b547e4463fb4751343f234 12; then
log -t recovery "Installing new recovery image"
applypatch EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5277696:5d7013bf98f76199ea5b7d7d8baeb07fa3ad26 ff EMMC:/dev/block/platform/sdhci-tegra.3/by-name/SOS f80238c4f4a53888b547e4463fb4751343f23412 5906432 5d7013bf98f76199ea5b7d7d8baeb07fa3ad26ff:/system/recovery-from-boot.p
else
log -t recovery "Recovery image already installed"
fi

but I can't make any sense of it. If anyone can help out i'd much appreciate it...
Last edited by sonofskywalker3; 24th May 2013 at 03:21 AM.
The Following 11 Users Say Thank You to sonofskywalker3 For This Useful Post: [ View ]
24th May 2013, 01:14 PM   |  #2  
mybook4's Avatar
Senior Member
Thanks Meter: 263
 
444 posts
Join Date:Joined: Apr 2011
Donate to Me
More
Quote:
Originally Posted by sonofskywalker3

but I can't make any sense of it. If anyone can help out i'd much appreciate it...


This seems to be the magic lines in the update script:

Quote:

if ! applypatch -c EMMC:/dev/block/platform/sdhci-tegra.3/by-name/SOS:5906432:f80238c4f4a53888b547e4463fb4751343f234 12; then
log -t recovery "Installing new recovery image"
applypatch EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5277696:5d7013bf98f76199ea5b7d7d8baeb07fa3ad26 ff EMMC:/dev/block/platform/sdhci-tegra.3/by-name/SOS f80238c4f4a53888b547e4463fb4751343f23412 5906432 5d7013bf98f76199ea5b7d7d8baeb07fa3ad26ff:/system/recovery-from-boot.p

I don't know much about the applypatch program. It might just be another script. Since it isn't being called with a "./", I'd imagine it is installed somewhere that the path mentions. Try looking for "applypatch" to see if it is a program or script. In a terminal running on the Ouya, try running "echo $PATH". Hopefully you get a list of directories containing program locations (e.g. /usr/bin/ ...etc). Applypatch might be in one of those directories.


UPDATE 1:
applypatch is a binary, not a script. It is located in /system/bin/
I tried running it without arguments on my Nexus 7 (to see if we would luck out with a nice "usage" message), but for some annoying reason I can't give it execute permissions, even as root. I'll look deeper into the scripts

UPDATE 2:
I need to verify this on my Ouya, but from the updater-script in the latest OTA, the kernel partition is /dev/block/platform/sdhci-tegra.3/by-name/LNX (I'm going out on a limb here boys, but I think LNX stands for Linux, aka, our kernel, lol).

UPDATE 3:
Seems like the recovery partition is /dev/block/platform/sdhci-tegra.3/by-name/SOS
I don't know much about the details of "applypatch", but the recovery script you posted above seems to first check to see if the recovery partition hashes to f80238c4f4a53888b547e4463fb4751343f23412 (the hash of the latest and greatest recovery). If it doesn't, then we flash the latest recovery, which from the looks of it consists of the kernel (in LNX) with a patch applied to it from recovery-from-boot.p (another mess of binary). In other words, it looks like they build a recovery from the existing kernel, as the name "recovery-from-boot" implies (the kernel is packaged in a file called boot.img).

Long story short, it looks like you can write to the block device /dev/block/platform/sdhci-tegra.3/by-name/SOS to write a new recovery. Aka, in a hacked version of the OTA script, include the line

package_extract_file("recovery.img", "/dev/block/platform/sdhci-tegra.3/by-name/SOS");

where recovery.img is the name of your new recovery. They did something very similar to the kernel (LNX). I'm pretty sure that the correct way to do something like this is to use "dd" after verifying the image is correct (by running a hash against the image). I'm not sure why the Ouya team is using package_extract_file() instead of dd. I'm not in front of my Ouya though, LNX and SOS could be folders rather than block devices (although /dev/block seems to imply otherwise).

You can remove most of the other lines in the script that install the actual OTA update files. If you need help, let me know. I can make a custom update-script for you.


WARNING!!!!!!!! The above is just my take on things from looking at the scripts for 20 minutes. This could total brick your device if your recovery isn't of the right format or is not correctly built. Don't say I didn't warn ya.

You might want to read off the contents of the SOS to compare in a hex editor to your recovery. We might find out some things that would prevent a brick.




Sent from my Nexus 7 using xda premium
Last edited by mybook4; 24th May 2013 at 02:23 PM.
The Following User Says Thank You to mybook4 For This Useful Post: [ View ]
24th May 2013, 03:45 PM   |  #3  
sonofskywalker3's Avatar
OP Senior Member
Thanks Meter: 283
 
729 posts
Join Date:Joined: Jan 2009
Donate to Me
Thank you for all your detailed information. I assumed that if my cwm recovery build failed I could just flash the boot.img from the ota and restore it, but it sounds like that might not be correct if the update is dependent on a hashed, preexisting recovery/kernel. I used the boot.img from the ota to build the recovery at http://builder.clockworkmod.com/ and it showed successful and gave me these four files:

https://dl.dropboxusercontent.com/u/7653846/Archive.zip

So to test, should I be able to flash_image /dev/block/platform/sdhci-tegra.3/by-name/SOS recovery.img?
my concern is that particular block doesn't show up on a mount command...
24th May 2013, 06:01 PM   |  #4  
mybook4's Avatar
Senior Member
Thanks Meter: 263
 
444 posts
Join Date:Joined: Apr 2011
Donate to Me
More
Quote:
Originally Posted by sonofskywalker3

Thank you for all your detailed information. I assumed that if my cwm recovery build failed I could just flash the boot.img from the ota and restore it, but it sounds like that might not be correct if the update is dependent on a hashed, preexisting recovery/kernel. I used the boot.img from the ota to build the recovery at http://builder.clockworkmod.com/ and it showed successful and gave me these four files:

https://dl.dropboxusercontent.com/u/7653846/Archive.zip

So to test, should I be able to flash_image /dev/block/platform/sdhci-tegra.3/by-name/SOS recovery.img?
my concern is that particular block doesn't show up on a mount command...

I'm putting together an zip to flash in the stock recovery. This way we mimic what the stock updates do to flash over partitions.

I'm reading http://forums.ouya.tv/discussion/1380/recovery-mode right now in order to figure out how to get into the stock recovery.

One thing that I noticed is that I think your recovery is slightly larger than the stock one. I'm not sure how large SOS is, but I wouldn't want to flash over adjacent blocks (i.e. write out of bounds).
Last edited by mybook4; 24th May 2013 at 07:31 PM.
24th May 2013, 06:17 PM   |  #5  
sonofskywalker3's Avatar
OP Senior Member
Thanks Meter: 283
 
729 posts
Join Date:Joined: Jan 2009
Donate to Me
Makes sense. You must know something I don't if you can get it to flash in stock recovery... I tried simply adding files to the ota zip and flashing it and it failed.
24th May 2013, 07:56 PM   |  #6  
mybook4's Avatar
Senior Member
Thanks Meter: 263
 
444 posts
Join Date:Joined: Apr 2011
Donate to Me
More
Quote:
Originally Posted by sonofskywalker3

Makes sense. You must know something I don't if you can get it to flash in stock recovery... I tried simply adding files to the ota zip and flashing it and it failed.

It probably doesn't work because the update.zip we're using is signed.

Just a thought, but an easier way to go, albeit dangerous, is to do the following. You need root access over adb to do this. Using dd is VERY dangerous. THIS MIGHT NOT WORK. We need to make sure that what we are writing to (/dev/block/platform/sdhci-tegra.3/by-name/SOS) is truly the block device containing the recovery partition or else this might brick the Ouya. In the past, I've seen recovery written to /dev/block/mmcblk0pX, where X is the recovery partition for the particular device. I'm not much of a tegra guy. I know more about Samsung's stuff.

1) place the recovery.img on your ouya (let's say in /sdcard/recovery.img)
2) open a terminal running on your Ouya (over adb would probably be best, e.g. "adb shell")
3) enter a root shell, type "su"
4) make a backup of your existing recovery partition with "dd if=/dev/block/mmcblk0p1 of=/sdcard/origRecovery.img"
5) write the new recovery to the recovery partition with "dd if=/sdcard/recovery.img of=/dev/block/mmcblk0p1"

6) perform the following from user mbm in the Ouya forums to get into recovery (thread http://forums.ouya.tv/discussion/1380/recovery-mode)

Quote:

This is a hack, an unintended sequence of events that results in recovery mode; what you need to do is crash the startup using sysrq.

For this you'll need a usb keyboard with the sysrq key, this is usually the printscreen button if your keyboard isn't labeled. As the OUYA starts to boot, hold down the alt-sysrq keys and press i, wait a few seconds and then repeat. This key combination is kill-all-tasks; thanks to whoever left this enabled in the kernel. Each time you kill the tasks the init process will restart them, after about 5 or 6 times init will print a warning on the console that one of the processes marked critical has been restarted too many times -- this then triggers an automatic reboot into recovery mode.

Unfortunately it's not always obvious when the ouya is in recovery mode. You might get screen with the ouya logo and a large red exclamation mark, or the screen might be entirely black; usually I got a black screen. Press the home button on the keyboard to bring up the recovery menu; it's actually a toggle so feel free to press the home button repeatedly until you see the menu since the timing isn't otherwise obvious.

There are two big unknowns here:

1) We don't know for sure that the new recovery (CWM) will actually work
2) We don't know for sure that /dev/block/platform/sdhci-tegra.3/by-name/SOS is the correct place to be writing a recovery


I'll see what I can dig up regarding /dev/block/platform/sdhci-tegra.3/by-name/SOS

---------- Post added at 02:53 PM ---------- Previous post was at 02:30 PM ----------

/dev/block/platform/sdhci-tegra.3/by-name/SOS is a link to /dev/block/mmcblk0p1


So far, it appears that the layout is the following:

Kernel (boot.img) is mmcblk0p2
Recovery is mmcblk0p1
System is mmcblk0p3


Sent from my SCH-I535 using xda premium

---------- Post added at 02:56 PM ---------- Previous post was at 02:53 PM ----------

I would imagine that if the recovery partition really is SOS, then the above steps would work if you could run them as root.

Sent from my SCH-I535 using xda premium
Last edited by mybook4; 24th May 2013 at 07:58 PM.
24th May 2013, 09:28 PM   |  #7  
Recognized Developer
Thanks Meter: 1,091
 
248 posts
Join Date:Joined: May 2008
Donate to Me
More
Some definite info:
  • SOS is recovery
  • OUYA firmware updates patches the boot partition on the fly (binary patching) - silly and error prone, but *shrug*. Don't need apply patch at all. dd is fine
  • It's much safer to use 'fastboot boot recovery.img' while in fastboot mode. This allows loading recovery or boot.img's into ram and execute them from there. Once that works 100%, you can flash it to SOS.
  • As most people already know, it's not possible to force the device into recovery. It has to be done with something like 'adb reboot recovery'.
The Following 3 Users Say Thank You to rayman For This Useful Post: [ View ]
24th May 2013, 09:37 PM   |  #8  
Recognized Developer
Thanks Meter: 1,091
 
248 posts
Join Date:Joined: May 2008
Donate to Me
More
Quote:
Originally Posted by mybook4

I'm putting together an zip to flash in the stock recovery. This way we mimic what the stock updates do to flash over partitions.

I'm reading http://forums.ouya.tv/discussion/1380/recovery-mode right now in order to figure out how to get into the stock recovery.

One thing that I noticed is that I think your recovery is slightly larger than the stock one. I'm not sure how large SOS is, but I wouldn't want to flash over adjacent blocks (i.e. write out of bounds).

It's 8MB. If you dd to the block device (e.g. mmcblk0p1), you can't write out of bounds. The linux kernel knows the size and refuses it.
The Following User Says Thank You to rayman For This Useful Post: [ View ]
24th May 2013, 10:56 PM   |  #9  
mybook4's Avatar
Senior Member
Thanks Meter: 263
 
444 posts
Join Date:Joined: Apr 2011
Donate to Me
More
Quote:
Originally Posted by rayman

Some definite info:

  • SOS is recovery
  • OUYA firmware updates patches the boot partition on the fly (binary patching) - silly and error prone, but *shrug*. Don't need apply patch at all. dd is fine
  • It's much safer to use 'fastboot boot recovery.img' while in fastboot mode. This allows loading recovery or boot.img's into ram and execute them from there. Once that works 100%, you can flash it to SOS.
  • As most people already know, it's not possible to force the device into recovery. It has to be done with something like 'adb reboot recovery'.


I did the following with skywalker's recovery.

1) Attached a usb keyboard to the Ouya's full size usb port
2) Attached my computer to the Ouya's micr usb port
3) Ran "adb reboot bootloader" (the Ouya rebooted to a blank screen)
4) Waited 30 seconds and ran "fastboot boot recovery.img" (skywalker's recovery file)

The Ouya rebooted into CWM Recovery v6.0.3.2!
Error messages were encountered on the recovery screen (image attached)

5) Navigated around CWM with the arrow keys and the enter key
6) Rebooted with "reboot system now". Ouya booted right up.


When we flash the recovery to mmcblk0p1, we should rename /system/etc/install-recovery.sh (and maybe /system/recovery-from-boot.p) to prevent the recovery partition from being overwritten.

Looks like we need to adjust the recovery so it properly mounts the partitions. Hopefully after that we are good to go.
Attached Thumbnails
Click image for larger version

Name:	IMG_20130524_175410.jpg
Views:	526
Size:	247.3 KB
ID:	1988511  
Last edited by mybook4; 24th May 2013 at 11:24 PM.
The Following 4 Users Say Thank You to mybook4 For This Useful Post: [ View ]
25th May 2013, 12:30 AM   |  #10  
sonofskywalker3's Avatar
OP Senior Member
Thanks Meter: 283
 
729 posts
Join Date:Joined: Jan 2009
Donate to Me
Wow, that's awesome progress! So I'll try the same steps when I get home tonight and then try building another recovery with proper mount points.

Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Top Threads in Ouya Android Development by ThreadRank