[DUAL-BOOT][RECOVERY] Ouya Boot Menu for Support of Kernel Image Chain-loading

Search This thread

Hal9k+1

Member
Aug 9, 2013
43
31
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! :cool:
An additional support forum that everyone should be able to post at is available: http://forum.xda-developers.com/showthread.php?t=2450711.
 

Attachments

  • boot102513.zip
    6.9 MB · Views: 802
  • rcvy102513.zip
    6.9 MB · Views: 493
  • src_102513.zip
    38.5 KB · Views: 399
Last edited:

nchantmnt

Senior Member
Jan 26, 2012
535
185
Yes im happy it already arrived, but after a second miscarriage and lots of stress because of a lawsuit with our neighbour i didn't have time nor nerves to play or code. Seriously this year sucks ;)

Gesendet von meinem One X+ mit Tapatalk
 

Hal9k+1

Member
Aug 9, 2013
43
31
Yes im happy it already arrived, but after a second miscarriage and lots of stress because of a lawsuit with our neighbour i didn't have time nor nerves to play or code. Seriously this year sucks ;)

Gosh, I'm very sorry to hear that. Do think ahead to the upcoming holiday season, and may it be a time to reflect and anticipate a fruitful 2014.
 

Ipse_Tase

Senior Member
Feb 29, 2012
682
115
Samsung Galaxy S21 Ultra
@Hal9k+1 - THANK YOU!

I was so nervous flashing CWM and StockPlus as there is no real way to fix things if something goes wrong. This should give people more confidence when flashing their Ouya.

I understand the process using ADB...my question is: can this be used from CWM somehow?

PS. I assume new kernel will always be flashable from CWM, the hack does not require 561 specifically.
 
Last edited:

Hal9k+1

Member
Aug 9, 2013
43
31
I understand the process using ADB...my question is: can this be used from CWM somehow?

Hi Ipse_Tase - I do hope the feature will be helpful to you and others.

As I think about your question, I suppose I could have have created a ZIP that would have been installed by CWM. Similarly I could have worked through some form of installation shell script. But for an important operation such as flashing, I prefer the one-at-a-time approach of the interactive shell.

Note that CWM does have an ADB service running with it. Your Ouya would show up as a different device while in CWM, so you'd need to enter Device Manager (Windows) and point the unknown device to the same ADB driver as used for the main ROM.

Alternatively you could skip ADB for this Ouya Boot Menu installation and set up an SSH server on your main ROM. I personally have installed "SSH Server" (Ice Cold Apps). I recall two screens to set up (does require the trackpad in cases), where I enabled automatic start on both, and also set the port number to 2222. After an Ouya reboot I had SSH/SCP capability and could use PuTTY/pscp from Windows.
 

Ipse_Tase

Senior Member
Feb 29, 2012
682
115
Samsung Galaxy S21 Ultra
Hal9k+1...fast reply, thank you.
Just to put my ever-so-senile brain at ease: so I run StockPlus 519r1, and WHILE in the ROM, I start ADB and follow your instructions .
OR...I enter CWM, make sure I get the right ADB drivers installed for THAT instance and go from there.

For a developer, I'm sure it's easier and more familiar to run ADB commands - for people like me (5%-over-the average-user) a CVM option to flash a zip and do all this would be more in-line with the abilities to hack. :)
I have rooted 4-5 devices so far and the only time I type any ADB commands is at root/unlock time - sometimes not even then (Nexus 4 and the Root Toolkit).
So if you ever consider creating a recovery flashable file, it would help many. Probably not me, as by then I would have done the ADB trick :)
 

Trooper_Max

Senior Member
Jan 27, 2011
153
49
Sounds like great work! I was hoping to implement something like this myself, but I haven't made any more time for OUYA-related development in a while (due to positive life events/busyness)

I will definitely take a look at your work when I have time!

~Troop
 
  • Like
Reactions: Hal9k+1

Hal9k+1

Member
Aug 9, 2013
43
31
Hal9k+1...fast reply, thank you.
Just to put my ever-so-senile brain at ease: so I run StockPlus 519r1, and WHILE in the ROM, I start ADB and follow your instructions .
OR...I enter CWM, make sure I get the right ADB drivers installed for THAT instance and go from there.

You got it! You don't need to worry about booting to the other partition prior to flashing. That is a given partition (LNX/SOS) is no longer being accessed once the image is booted. For CWM's ADB, you'd simply point Windows to the same INF file that you originally used. Hope this helps.
 

Hal9k+1

Member
Aug 9, 2013
43
31
StockPlus Installation

Well, I finally retired this old stock 393 ROM I was on, and moved to StockPlus 519r2. I was not able to install it the normal way given my Boot image is in place here. So I ended up modifying "updater-script" under META-INF/com/google/android, and then repackaged prior to running the install procedure. I'm attaching my changed version in case it helps anyone, and please note that it makes StockPlus the main image (kernel.img).

(You'll need to right-click to save the attachment. Once done it will need to be renamed such that it does not include the ".txt" suffix.)

The Windows "7-Zip" utility is helpful for packaging. You may start by right-clicking the downloaded ZIP, then 7-Zip --> Extract to "OUYA_[...]". Enter the newly created directory, get to the updater-script, and replace it with mine. Now back up to the area with META-INF, system, and boot.img, still in the new directory. Select all three under Windows (Ctrl+Click), right click that area, and then 7-Zip --> Add to "OUYA_[...].zip". Be sure this new ZIP is the one that makes it to the Ouya.
 

Attachments

  • updater-script.txt
    4.3 KB · Views: 85
  • Like
Reactions: laynlow

Trooper_Max

Senior Member
Jan 27, 2011
153
49
Still haven't tried this out yet, but I hope to soon.

I missed out on news over the holidays though and just noticed this:

Announcing Ubuntu and Android dual boot developer preview
http://developer.ubuntu.com/2013/12/announcing-ubuntu-and-android-dual-boot-developer-preview/

I'm curious of their dual boot implementation and how it compares and if we can synergize with their approach, but haven't looked into the details of how theirs works yet (its sounds like it uses a custom recovery image, and they have the ability to trigger it to reboot into Ubuntu from an Android app and vice versa, which is cool)

It'd be awesome to be able to multi-boot an Ouya ROM, an Android ROM (CyanogenMod), and Ubuntu with that kind of ease.

EDIT: This may be more our speed though: (MultiROM)
http://forum.xda-developers.com/showthread.php?t=2011403
(did you pull anything from there? Sounds like they have a modified TWRP that can flash zips to the other ROM slots, which is something I was also hoping to implement)

~Troop
 
Last edited:

Hal9k+1

Member
Aug 9, 2013
43
31
Thanks, Trooper. Good to see Ubuntu moving further along in the mobile world.

I briefly looked at MultiROM since it originated from the KExec-HardBoot work, but decided not to go in that direction. The main reason is that I decided not to pursue the setup/learning of an Android build environment, but also because it wasn't clear how I'd deal with our lack of a touchscreen and lack of volume up/down buttons. I ended up creating a small application that fits within Ouya's CWM framework and starts up before CWM itself; it monitors the power button for click events and writes to the framebuffer memory region using regular Linux calls.

I'm not too concerned about the dual-boot aspect of this new Ubuntu, but the lack of touchscreen could be a hindrance if mouse/keyboard were not a viable substitute. Whether this Ubuntu is designed to work from external storage is another question, since our /system and /data would be occupied by Android. But in general I think we could boot it from my framework, and if my Boot image were selected over the Recovery one, then the Ubuntu kernel could reside in Recovery and also be bootable from the Android side with the "reboot recovery" command.

Best of luck, and hope you'll have a chance to try it all!
 

Top Liked Posts

  • There are no posts matching your filters.
  • 16
    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! :cool:
    An additional support forum that everyone should be able to post at is available: http://forum.xda-developers.com/showthread.php?t=2450711.
    2
    Thanks, Trooper. Good to see Ubuntu moving further along in the mobile world.

    I briefly looked at MultiROM since it originated from the KExec-HardBoot work, but decided not to go in that direction. The main reason is that I decided not to pursue the setup/learning of an Android build environment, but also because it wasn't clear how I'd deal with our lack of a touchscreen and lack of volume up/down buttons. I ended up creating a small application that fits within Ouya's CWM framework and starts up before CWM itself; it monitors the power button for click events and writes to the framebuffer memory region using regular Linux calls.

    I'm not too concerned about the dual-boot aspect of this new Ubuntu, but the lack of touchscreen could be a hindrance if mouse/keyboard were not a viable substitute. Whether this Ubuntu is designed to work from external storage is another question, since our /system and /data would be occupied by Android. But in general I think we could boot it from my framework, and if my Boot image were selected over the Recovery one, then the Ubuntu kernel could reside in Recovery and also be bootable from the Android side with the "reboot recovery" command.

    Best of luck, and hope you'll have a chance to try it all!
    1
    Sounds like great work! I was hoping to implement something like this myself, but I haven't made any more time for OUYA-related development in a while (due to positive life events/busyness)

    I will definitely take a look at your work when I have time!

    ~Troop
    1
    StockPlus Installation

    Well, I finally retired this old stock 393 ROM I was on, and moved to StockPlus 519r2. I was not able to install it the normal way given my Boot image is in place here. So I ended up modifying "updater-script" under META-INF/com/google/android, and then repackaged prior to running the install procedure. I'm attaching my changed version in case it helps anyone, and please note that it makes StockPlus the main image (kernel.img).

    (You'll need to right-click to save the attachment. Once done it will need to be renamed such that it does not include the ".txt" suffix.)

    The Windows "7-Zip" utility is helpful for packaging. You may start by right-clicking the downloaded ZIP, then 7-Zip --> Extract to "OUYA_[...]". Enter the newly created directory, get to the updater-script, and replace it with mine. Now back up to the area with META-INF, system, and boot.img, still in the new directory. Select all three under Windows (Ctrl+Click), right click that area, and then 7-Zip --> Add to "OUYA_[...].zip". Be sure this new ZIP is the one that makes it to the Ouya.