Hello everyone! Just like others here, I've been somewhat spooked by our inability to enter Ouya's Recovery partition at the earliest stage of booting, meaning a bad flash of the Boot partition would leave the device inoperable. When I heard that Ouya's stock firmware updates were possibly bricking a few units out there, I decided to block updates on mine and see if I could transform the Boot partition such that it would become a logical extension of the bootloader. What I ended up with is something close to the "Ouya Safe Recovery" project, where a user should only need to flash Boot one additional time, along with chain-loading support as well.
Chain-loading in this case refers to the booting of ROM kernel images that reside as regular IMG files under the /sdcard and/or /system filesystems. With this capability it is possible to choose an image to run when the Ouya turns on. As an example, one may wish to set up a 2nd/test kernel+ramdisk image to use with your installed ROM, or he may wish to run Tuomas Kulve's Debian project from time-to-time without having to set up the USB cable for Fastboot mode. When dealing with distinctly different ROMs (not just alternate kernels), only one of them may install to the Ouya's built-in storage (e.g., /system); others must have been designed/created to use external storage.
An image for the Recovery partition is available along with the Boot. The former may be helpful if you wish to try out the boot menu before performing the flash of the Boot partition, or are generally okay with bouncing to Recovery before invoking a chain-load. Either of these may be tested from Fastboot mode, but do note that a successful chain-load requires that the image actually be flashed to the Ouya. (Otherwise it just reboots.) The ClockworkMod (CWM) recovery application is available on both images and is accessible from the boot menu.
Additional Information
There are a few things to consider when deciding if this approach makes sense for you:
- Users of the "Ouya Safe Recovery" project may want to stay put unless the dual-boot aspect is of interest. If so then it would be cleanest to choose my Boot image; the Recovery partition (your ROM image) could be left alone.
- The images here are not compatible with Ouya's stock firmware, due to the auto-update nature of Ouya's ROM. Either your flashed Boot image would get overwritten, or an installed non-Ouya Recovery might cause that update to hang. Therefore, you should be prepared to switch to one of the ROMs here at XDA. If you're currently on stock and don't want to switch right away, that's fine; we'll go over how to block updates for the time being.
- The Ouya CM10 ROM is nice in that it provides the IMG file separately, allowing us to handle it as we wish. However, the other ROMs end up placing their boot.img in the main ZIP. This is standard practice for other devices, but we need to be careful ensuring our Boot partition doesn't get reflashed as part of the ROM installation. Therefore, it would be necessary to investigate repackaging the ROM with an alternate updater-script prior to installation. See my StockPlus post on page 2 for more. (This shouldn't affect those who've opted for my Recovery image.)
This feature is based on CWM's initial ramdisk, and includes a new boot menu application that comes up prior to CWM itself. Basically, CWM shows up later if the menu application exits for any reason. The Ouya stock kernel (561) has also been compiled with HDMI's copy protection turned off, and includes two patch sets:
- KExec-HardBoot is the key to chain-loading on our platform. It overcomes standard KExec's lack of hardware reset (and thus failed execution) by triggering a reboot in the middle of the preparation of the new kernel. This ingenious system has been developed by Tasssadar and others over in the Nexus forums. (Be sure to enable CONFIG_TEGRA_HARDBOOT_RECOVERY if interested in compiling a Recovery kernel.)
- HDMI visual stability has been improved with a little hack of mine: a significant relaxing of a timer in the driver. (The latest Android source has corrected the instability with a significant design change, but my hack seems fine enough for this project.) Also picked up specific Android fixes in the area of Framebuffer double-buffering, as that needs to be working for CWM usability.
Installation
If you're on Ouya's stock firmware, then you should make sure that any future updates do not get applied. There is a project here ("Mod Collection For Ouya") that should help. I personally side-loaded the Baxy custom launcher to avoid Ouya's update environment. It is also likely necessary to stay out of the Ouya/Discover store if going the custom launcher route as I believe the store app can trigger an update.
At this point you can download your chosen image (Boot or Recovery) and unzip to get the IMG file. Boot your Ouya to a working Root/BusyBox environment (ROM or Recovery), and then transfer the IMG to the Ouya. (An example using ADB would be "adb push boot102513.img /sdcard/boot102513.img".)
Bring up the Ouya command prompt (e.g., "adb shell") and run these commands to get started:
su [command not present on CWM - that's okay]
cd /dev/block/platform/sdhci-tegra.3/by-name
ls
You should see the various 3-letter partition names from that last command. Your command prompt should also contain the "#" character to denote root-level access. This next step will save off your current ROM image, both because we may end up overwriting it, and because the saved file will end up as your main bootable kernel for the chain-loader. Run:
cat LNX > /sdcard/kernel.img
(If configured for "Ouya Safe Recovery," then replace the preceding "LNX" with "SOS".)
We are near the flashing stage. Check to make sure your Ouya has a reliable source of power, preferrably from an uninterruptable power supply. Recall that a bad flash of my boot image can leave the device inoperable, but I feel the risk is very low provided the following directions are heeded. Fortunately the flash process only takes a few seconds.
For the Boot image option, verify by running:
md5sum /sdcard/boot102513.img
Do not proceed unless you get "e4b1b1ad553e55ad0b2ce3fb8f5bf623".
Again for the Boot image option, flash to the Ouya by running:
dd if=/sdcard/boot102513.img of=LNX
For the Recovery image option, verify by running:
md5sum /sdcard/rcvy102513.img
Do not proceed unless you get "dda0811a7e8e82a7d4ad3fa4c3ae35e4".
Again for the Recovery image option, flash to the Ouya by running:
dd if=/sdcard/rcvy102513.img of=SOS
You may optionally verify (post-flash) by running "md5sum" on the partition name. Finish up with these commands:
sync
reboot
Usage / Configuration
The menu should come up, defaulting to "kernel.img" for the Boot image and "CWM" for Recovery. That default will then launch after ten seconds of inactivity. You may also briefly press the Ouya power button during the wait to advance through the options. The option list is 1) kernel.img, 2) kernelA1.img, 3) kernelA2.img, 4) CWM, and 5) Recovery Partition.
The defaults from above should be fine for most everyone, but it is possible to fine-tune them. An optional configuration file (/sdcard/bootmenu_b.cfg for Boot, /sdcard/bootmenu_r.cfg for Recovery) may be established to specify the default menu entry as well as the inactivity timeout. As an example, the following command would make Recovery start kernelA1.img after five seconds:
echo "2 5" > /sdcard/bootmenu_r.cfg
It is hoped that the menu would never hang. If it does, then waiting a full minute should allow CWM to start. Otherwise, it may be necessary to attach a wired/USB keyboard and type in the Alt-SysRq-X sequence, similar to Ctrl-Alt-Delete on a PC. The sequence might have to be done early on in the menu startup process, and should blink the Ouya light and place it in Fastboot mode.
The menu may unexpectedly place you in CWM, which would indicate an issue with a chain-load. The reason may be due to a missing or corrupt IMG file. Otherwise you should be able to determine why by checking /tmp/bootmenu.log against the attached source code.
---
I hope this project will be of help to others!
An additional support forum that everyone should be able to post at is available: http://forum.xda-developers.com/showthread.php?t=2450711.
Chain-loading in this case refers to the booting of ROM kernel images that reside as regular IMG files under the /sdcard and/or /system filesystems. With this capability it is possible to choose an image to run when the Ouya turns on. As an example, one may wish to set up a 2nd/test kernel+ramdisk image to use with your installed ROM, or he may wish to run Tuomas Kulve's Debian project from time-to-time without having to set up the USB cable for Fastboot mode. When dealing with distinctly different ROMs (not just alternate kernels), only one of them may install to the Ouya's built-in storage (e.g., /system); others must have been designed/created to use external storage.
An image for the Recovery partition is available along with the Boot. The former may be helpful if you wish to try out the boot menu before performing the flash of the Boot partition, or are generally okay with bouncing to Recovery before invoking a chain-load. Either of these may be tested from Fastboot mode, but do note that a successful chain-load requires that the image actually be flashed to the Ouya. (Otherwise it just reboots.) The ClockworkMod (CWM) recovery application is available on both images and is accessible from the boot menu.
Additional Information
There are a few things to consider when deciding if this approach makes sense for you:
- Users of the "Ouya Safe Recovery" project may want to stay put unless the dual-boot aspect is of interest. If so then it would be cleanest to choose my Boot image; the Recovery partition (your ROM image) could be left alone.
- The images here are not compatible with Ouya's stock firmware, due to the auto-update nature of Ouya's ROM. Either your flashed Boot image would get overwritten, or an installed non-Ouya Recovery might cause that update to hang. Therefore, you should be prepared to switch to one of the ROMs here at XDA. If you're currently on stock and don't want to switch right away, that's fine; we'll go over how to block updates for the time being.
- The Ouya CM10 ROM is nice in that it provides the IMG file separately, allowing us to handle it as we wish. However, the other ROMs end up placing their boot.img in the main ZIP. This is standard practice for other devices, but we need to be careful ensuring our Boot partition doesn't get reflashed as part of the ROM installation. Therefore, it would be necessary to investigate repackaging the ROM with an alternate updater-script prior to installation. See my StockPlus post on page 2 for more. (This shouldn't affect those who've opted for my Recovery image.)
This feature is based on CWM's initial ramdisk, and includes a new boot menu application that comes up prior to CWM itself. Basically, CWM shows up later if the menu application exits for any reason. The Ouya stock kernel (561) has also been compiled with HDMI's copy protection turned off, and includes two patch sets:
- KExec-HardBoot is the key to chain-loading on our platform. It overcomes standard KExec's lack of hardware reset (and thus failed execution) by triggering a reboot in the middle of the preparation of the new kernel. This ingenious system has been developed by Tasssadar and others over in the Nexus forums. (Be sure to enable CONFIG_TEGRA_HARDBOOT_RECOVERY if interested in compiling a Recovery kernel.)
- HDMI visual stability has been improved with a little hack of mine: a significant relaxing of a timer in the driver. (The latest Android source has corrected the instability with a significant design change, but my hack seems fine enough for this project.) Also picked up specific Android fixes in the area of Framebuffer double-buffering, as that needs to be working for CWM usability.
Installation
If you're on Ouya's stock firmware, then you should make sure that any future updates do not get applied. There is a project here ("Mod Collection For Ouya") that should help. I personally side-loaded the Baxy custom launcher to avoid Ouya's update environment. It is also likely necessary to stay out of the Ouya/Discover store if going the custom launcher route as I believe the store app can trigger an update.
At this point you can download your chosen image (Boot or Recovery) and unzip to get the IMG file. Boot your Ouya to a working Root/BusyBox environment (ROM or Recovery), and then transfer the IMG to the Ouya. (An example using ADB would be "adb push boot102513.img /sdcard/boot102513.img".)
Bring up the Ouya command prompt (e.g., "adb shell") and run these commands to get started:
su [command not present on CWM - that's okay]
cd /dev/block/platform/sdhci-tegra.3/by-name
ls
You should see the various 3-letter partition names from that last command. Your command prompt should also contain the "#" character to denote root-level access. This next step will save off your current ROM image, both because we may end up overwriting it, and because the saved file will end up as your main bootable kernel for the chain-loader. Run:
cat LNX > /sdcard/kernel.img
(If configured for "Ouya Safe Recovery," then replace the preceding "LNX" with "SOS".)
We are near the flashing stage. Check to make sure your Ouya has a reliable source of power, preferrably from an uninterruptable power supply. Recall that a bad flash of my boot image can leave the device inoperable, but I feel the risk is very low provided the following directions are heeded. Fortunately the flash process only takes a few seconds.
For the Boot image option, verify by running:
md5sum /sdcard/boot102513.img
Do not proceed unless you get "e4b1b1ad553e55ad0b2ce3fb8f5bf623".
Again for the Boot image option, flash to the Ouya by running:
dd if=/sdcard/boot102513.img of=LNX
For the Recovery image option, verify by running:
md5sum /sdcard/rcvy102513.img
Do not proceed unless you get "dda0811a7e8e82a7d4ad3fa4c3ae35e4".
Again for the Recovery image option, flash to the Ouya by running:
dd if=/sdcard/rcvy102513.img of=SOS
You may optionally verify (post-flash) by running "md5sum" on the partition name. Finish up with these commands:
sync
reboot
Usage / Configuration
The menu should come up, defaulting to "kernel.img" for the Boot image and "CWM" for Recovery. That default will then launch after ten seconds of inactivity. You may also briefly press the Ouya power button during the wait to advance through the options. The option list is 1) kernel.img, 2) kernelA1.img, 3) kernelA2.img, 4) CWM, and 5) Recovery Partition.
The defaults from above should be fine for most everyone, but it is possible to fine-tune them. An optional configuration file (/sdcard/bootmenu_b.cfg for Boot, /sdcard/bootmenu_r.cfg for Recovery) may be established to specify the default menu entry as well as the inactivity timeout. As an example, the following command would make Recovery start kernelA1.img after five seconds:
echo "2 5" > /sdcard/bootmenu_r.cfg
It is hoped that the menu would never hang. If it does, then waiting a full minute should allow CWM to start. Otherwise, it may be necessary to attach a wired/USB keyboard and type in the Alt-SysRq-X sequence, similar to Ctrl-Alt-Delete on a PC. The sequence might have to be done early on in the menu startup process, and should blink the Ouya light and place it in Fastboot mode.
The menu may unexpectedly place you in CWM, which would indicate an issue with a chain-load. The reason may be due to a missing or corrupt IMG file. Otherwise you should be able to determine why by checking /tmp/bootmenu.log against the attached source code.
---
I hope this project will be of help to others!
An additional support forum that everyone should be able to post at is available: http://forum.xda-developers.com/showthread.php?t=2450711.
Last edited:
