Debian on Ouya: All Systems Go

I finally got all the major subsystems working and Debian is now usable on Ouya. I prefer Debian but Ubuntu should work similarly.

Working video and 3D

In the above screenshot I’m playing 1080p H264 while running glmark2-es, an OpenGL ES benchmark. And the CPUFreq ondemand governor doesn’t even raise the CPU frequency from the minimum as everything is properly accelerated. I do have to admit that the 1080p video isn’t running smoothly with the benchmark running at the same time.

A disclaimer before telling more: Trying this out might void the warranty and flashing anything to Ouya may easily brick it forever. So don’t try it, unless you are willing to buy a new one.

That said, the idea is not to touch Ouya’s Android at all. Kernel is booted from RAM and Debian from an SD card or USB stick.

The instructions for debootstrapping your own Debian Wheezy rootfs are described in the github repository and the needed binaries are in a temporary location that will probably change at some point.

WiFi is working as well but I’m not sure if the firmware binaries are redistributable, so you need to copy them from the Android rootfs after booting to Debian.

One of my main goals for this whole exercise is video encoding and I’m happy to say that H264 encoding from an USB webcam works nicely with hardware acceleration as well.

I’ve also noticed some issues:

  • Hciconfig doesn’t show BT devices, I didn’t debug much further.
  • Mpg123 seems to play but nothing is heard. Maybe it tries to pass MP3 onwards instead of PCM? GStreamer provides acceleration for MP3 and AAC though.
  • Video acceleration works only with GStreamer and nvxvimagesink. Mplayer can’t even use XV video output correctly.
  • Tegra3 supports only OpenGL ES 2.0 with EGL, so no full OpenGL with GLX.
  • Xrandr seems to be able to switch the resolution but after the switch there was window decoration corruption.

Despite the deficiencies I think Tegra3 is quite well supported in the X.Org world and many things work well with this 99$ device.

If you test my instructions, let me know how it goes and what you think about it! :)

125 thoughts on “Debian on Ouya: All Systems Go

  • September 18, 2013 at 9:11 pm
    Permalink

    Does that mean you have solved sound issues ?

    Reply
    • September 19, 2013 at 8:34 am
      Permalink

      Yes, audio seems to work nicely now (with the exception of mpg123).

      Reply
      • September 19, 2013 at 5:44 pm
        Permalink

        Have you tried running xbmc on Debian ?
        What about movies with dts-HD master audio sound ?
        Android kernel is not capable of playing them correctly, openelec and other distorts support it.

        Reply
  • September 19, 2013 at 5:57 pm
    Permalink

    I haven’t tried XBMC. Video decode on Tegra is supported only through GStreamer. Do you know if XBMC supports that?

    I don’t know about dts-HD either. I’m practically using the same kernel as the Android but it do report stereo PCM and some multichannel stream when I plug in my TV.

    If you can point me to a sample audio/video file I can certainly try it out. (EDIT: Or do I actually need some special dts-HD capable TV/AVR to test that?)

    Reply
    • September 20, 2013 at 7:42 am
      Permalink

      You need a dts compatible receiver to try surround sound.
      I have necessary equipment hooked up to my ouya.
      I have prepared Debian according to your instructions (there is a bug in your description, regarding extraction of modules in chroot).
      I’m going to test it over the weekend, will let you know the results.

      Reply
      • September 20, 2013 at 8:01 am
        Permalink

        Well, I have a DTS compatible receiver, but not sure about those letters after the DTS :)

        EDIT: This is what my TV reports according to dmesg on Ouya:

        [ 40.370623] HDMI: detected monitor SONY TV at connection type HDMI
        [ 40.376926] HDMI: available speakers: FL/FR
        [ 40.381301] HDMI: supports coding type LPCM: channels = 2, rates = 44100 48000 88200, bits = 16 20 24
        [ 40.390888] HDMI: supports coding type AC-3: channels = 6, rates = 44100 48000 88200, max bitrate = 640000

        I don’t really know what the 6 channel AC-3 is for. And currently the ALSA conf is hard coded to 2 channels. Not sure how easy it is to try other configurations as I think the kernel side might be missing something.

        And thanks about the bug report. I moved it so that’s it’s run outside the chroot.

        Reply
      • November 25, 2014 at 4:32 pm
        Permalink

        I don’t want a temp solution, I want to wipe my ouya’s 8 gb and install debian on it, it just bought the second one to be a arm debian box, so I don’t give a crap about the ouya’s data.

        Reply
  • September 20, 2013 at 11:22 am
    Permalink

    that is awesome news. great work.

    Reply
  • September 20, 2013 at 7:08 pm
    Permalink

    I must be doing something wrong.
    When I try to fasboot the kernel image I get:
    cannot load ‘zImage-3.1.10-tk*’: No error

    Where should I put the kernel image ?

    Reply
    • September 20, 2013 at 7:19 pm
      Permalink

      Nevermind – I’ve got it running

      Reply
  • September 21, 2013 at 11:41 am
    Permalink

    Wow great, maybe a linux xbmc build can be done!

    Reply
  • September 26, 2013 at 4:00 pm
    Permalink

    I think there’s an error in the Readme file. You extract kernel modules after unmounting $TARGET.

    But whatever, that’s an awesome job, and open lot of possibilites for Ouya !

    Do you think that it’s possible to reboot ouya to Debian without adb commands ?

    Reply
  • September 26, 2013 at 10:09 pm
    Permalink

    Is there anyway to install this from Mac or Windows?

    Reply
    • September 27, 2013 at 12:54 pm
      Permalink

      I don’t think that will be easy to do, since the entire process require debian binaries.

      But you can try to do this trough VirtualBox (it should work), or if you’re lazy, ask a nice user to do a raw copy of his usb stick that you can clone on your !

      Reply
  • September 27, 2013 at 12:58 pm
    Permalink

    Here you are using debian bootstrap for creating a distro from scratch. Do you think that it is possible to fastboot to a modified debian installer ?

    Reply
    • September 27, 2013 at 1:06 pm
      Permalink

      I don’t know much about the debian installer but I guess it shouldn’t be too difficult.

      I’m basically just adding X.Org and ALSA configuration files, X.Org driver and Tegra binary blobs to the filesystem so it’s not heavily modified. And of course the kernel is completely custom compared to stock Debian.

      I’m providing the instructions for creating the filesystem from scratch as I don’t have network bandwidth for sharing big filesystem images. Although I guess nowadays Dropbox or Google Drive could work just fine.

      Providing a Debian installer that would install XFCE based system to a external USB flash drive would be quite cool. But if there’s a risk that it would install it over the Ouya Android, then it’s a bit risky.

      Reply
  • September 29, 2013 at 12:05 pm
    Permalink

    I am very interested in running linux on the ouya. This is great news, openelec here we come :)

    Reply
    • September 29, 2013 at 1:38 pm
      Permalink

      Unfortunately XBMC doesn’t seem to support GStreamer. There has been some patches to enable GStreamer but looks like they never got merged.

      RPi port of the OpenELEC uses OpenGL ES and OpenMAX IL and those are both supported in L4T as well, although OpenMAX IL has been marked as deprecated.

      So I’m not sure what would be the best approach to get OpenELEC running on Ouya. Probably OpenGL ES + GStreamer but then those GStreamer patches need to be merged from somewhere.

      Reply
      • October 1, 2013 at 5:05 am
        Permalink

        How about Crystalbuntu? It uses Ubuntu 12.04 build. I’ve been using CB on my ATV and it’s been running very smooth. I was searching for an alternative to the ATV (because they are hard to find now), when I came across your site. I’m sure the guys at CB forum can help you out with any problems you are having. I hope Sam ports his CB build over to Ouya in the future.
        http://forum.stmlabs.com/forumdisplay.php?fid=4
        http://www.crystalbuntu.com/

        Reply
        • October 1, 2013 at 8:36 am
          Permalink

          I did some very quick googling and I guess CB doesn’t use GStreamer either.

          Reply
  • October 1, 2013 at 8:41 am
    Permalink

    Maybe somebody should try out Plasma Media Center. I think that uses GST as the media backend.

    Debian Stable is too old for that though but I’m happy to help if somebody wants to try it on Ubuntu/whatever.

    Reply
    • October 1, 2013 at 8:48 am
      Permalink

      It’s not as good as XBMC (from what I can see). I know CB is built from the Ubuntu 12.04 build. Maybe if we had Ubuntu working with the Ouya we can get XBMC. I know guys are using XBMC on the Ubuntu desktop version.

      Reply
  • October 1, 2013 at 8:43 am
    Permalink

    GStreamer is for audio and video streaming? http://gstreamer.freedesktop.org/. Is this the only library to get audio/video? The developers on the CB forums are very helpful. They’ve helped me with a bunch of issues. I can ask them if they are willing to help with this project.

    Reply
  • October 1, 2013 at 8:52 am
    Permalink

    Yes, GStreamer is a audio/video framework and it’s the only one with HW acceleration support on Linux for Tegra on Ouya.

    There shouldn’t be any issues in getting Ubuntu running on Ouya with HW accelerated OpenGL ES and GStreamer. Unfortunately XBMC doesn’t support GStreamer, although I’ve seen some older patches for it.

    Reply
    • October 2, 2013 at 2:22 pm
      Permalink

      I don’t know if gstreamer in the only way for HW video decode… How does work xbmc for Ouya (droid version) ? How does work wbmc on any tegra 3 device ?

      I know that ffmpeg is a bit unstable with tegra 3, but maybe we can find an alternative !

      Reply
      • October 2, 2013 at 2:33 pm
        Permalink

        On Android Ouya of course supports Android’s multimedia framework but the Linux driver is a different thing.

        I don’t think FFMpeg supports any of the Tegra3′s video capabilities. Certainly it can be compiled for Tegra3 but that would be just a generic ARMv7 build using CPU only (although NEON would be supported).

        Maybe somebody should try out XBMC/OpenMAX with Ouya. Based on my earlier OMX tests on other platforms OMX players need to be always tweaked for the actual OMX implementation but maybe that would be doable. I guess the first thing would be to try out some simple OMX players and only then XBMC.

        Reply
  • October 1, 2013 at 9:05 am
    Permalink

    Unfortunately Tegra is a completely different thing than the desktop GPUs and so is the software support.

    Reply
  • October 4, 2013 at 8:28 pm
    Permalink

    I’ve booted up Ubuntu Saucy and tried to compile XBMC with OpenMAX, but I’m getting the following error:

    CPP xbmc/cores/dvdplayer/DVDCodecs/Video/OpenMaxVideo.o
    OpenMaxVideo.cpp:81:30: error: invalid use of incomplete type ‘class COpenMaxVideo’
    COpenMaxVideo::COpenMaxVideo()
    ^
    In file included from OpenMaxVideo.cpp:32:0:
    DVDVideoCodec.h:39:7: error: forward declaration of ‘class COpenMaxVideo’
    class COpenMaxVideo;
    ^

    Reply
    • October 27, 2013 at 4:50 pm
      Permalink

      Please please please let me know how this is progressing. A how-to would be appreciated also also. This is definitely one of my main intentions for the OUYA, to have an OUYABUNTU desktop to use as well as the regular OUYA system. Also, I can’t think of a better use of the hardware when it reaches obsolescence or we get a chance to upgrade to OUYA2 or whatever :)

      /mouth watering

      Reply
  • October 12, 2013 at 10:50 am
    Permalink

    Hi Tuomas,
    I bought the ouya for running Debian as a sort of thin client.
    I did not understand the part of fastboot in your description “install adb and fastboot to the host Debian” (is that my current desktop?) and where do I give the command “adb reboot-bootloader”?
    Thanks

    Reply
    • October 12, 2013 at 10:54 am
      Permalink

      Yes, you need to install adb and fastboot to your current desktop and run the adb and fastboot commands in there. They will communicate over the USB cable to their counterparts in Ouya.

      I’ve provided the adb and fastboot packages for Debian in the same place as the other packages. I’ve taken them from Ubuntu and recompiled for Debian, so for Ubuntu you can install them like any other application (“apt-get install android-tools-adb android-tools-fastboot” or using a GUI).

      Reply
  • October 27, 2013 at 10:20 pm
    Permalink

    Are you still working on this?

    Reply
    • October 27, 2013 at 10:31 pm
      Permalink

      What exactly?

      Reply
  • November 5, 2013 at 10:19 am
    Permalink

    could the final install be made into a .img file to boot from ?

    Reply
    • November 5, 2013 at 10:29 am
      Permalink

      At least with some initrd tinkering I think it should be possible to have a .img file in the /data partition of the Ouya and boot using that as the rootfs.

      Reply
      • November 7, 2013 at 10:36 pm
        Permalink

        If you were able to create an .img, would it be usable with the Ouya Boot Menu? If so, it’d be BEYOND awesome!

        Reply
        • November 8, 2013 at 10:07 am
          Permalink

          Yes, it should be possible. The only downside is that the .img would need to be at least 4GB even if the actual filesystem in it would be smaller. And then it would always take that 4GB away from /data partition.

          Reply
          • November 9, 2013 at 1:38 pm
            Permalink

            That sucks… Mostly, the reason I would be willing to use the .img is because I’m too much of a rookie to get Ubuntu to install on my USB. Would it be possible for you to upload your USB config? Thanks for your help

            Reply
  • November 9, 2013 at 3:59 pm
    Permalink

    Good discussion, all!
    A supported image for Ouya Boot Menu maxes out at 8Mb, just like the Boot partition itself. Still, this should let us fit in a minimal ramdisk. I could see it containing nothing more than CWM’s busybox environment along with a startup script. I’m hoping mkbootimg’s “cmdline” option (or direct kernel compile with command line) would somehow let us tell the kernel to use the script as the “init” program.

    The script would mount the bigger image that’s present in /sdcard (/data/media). I’m thinking it could be a SquashFS (compressed/read-only) image that’s mounted with “-o loop”. I don’t know if we could chroot inside that mount point, though the initial ramdisk could contain symlinks as a substitute.

    This is all quite speculative though, as I’m still a hardcore n00b in this stuff. :)

    Reply
    • November 11, 2013 at 3:47 pm
      Permalink

      Related to my earlier comment about the .img taking always 4GB away from Ouya’s flash. Isn’t Ouya going to support installing applications to an SD card? The .img file could be there as well and SD cards goes up to .. Well, up to a really big ones :) Then taking that 4GB always wouldn’t be that big of an issue.

      Reply
      • November 11, 2013 at 5:36 pm
        Permalink

        Thanks, Tuomas.
        I believe my idea, which originates from your idea, would not have that 4GB fixed-size restriction. Instead I feel even a 1GB image would make a usable system, as this concept is much the same as how Linux LiveCDs work. A user could later set up external storage for swap and additional applications if interested.

        I’d be happy to play around in this area to see if something could be made to work. However, I wonder if you could email or post a modified Ouya/Debian kernel image (CONFIG_SQUASHFS=”y” and CONFIG_CMDLINE=”") to get me going. Thanks!

        Reply
          • November 12, 2013 at 4:20 am
            Permalink

            Sweet! And I’m happy to say the kernel is working here, especially now that I realize I needed to pass in a couple of your parameters to enable the frame-buffer console. :)

            I have a rudimentary ramdisk set up with the kernel; it doesn’t do much right now – pauses for a number of seconds and then exits, triggering a kernel panic (since “init” shouldn’t ever exit). Still plenty to do, but at least it’s a start.

            Reply
  • November 10, 2013 at 10:59 pm
    Permalink

    Hi,
    I need some help. I tried to repeat the Tuomas scenario of making a USB-stick (512 MB Swap + 31.5 GB ext4 partition) and boot it from RAM but no success (in fact, tried it 4 times from scratch). I see the unit do a DHCP request (and it gets it ACKed) but those are all te live symptoms I’m getting. Black HDMI screen and no SSD connection possible.
    Environment: updated Ouya, having latest upfates till November 10 (Build#: 1.0561_r1, HW#: OUYA and SW#: 1.09), Debian Wheezy 7.2 Gnome 3.0 AMD64 host system. Sandisk extereme 32 GB USB 3.0 USB stick (no problems partitioning, formatting and doing the chroot scenario).

    The last steps I’m seeing:

    [~]# adb devices
    List of devices attached
    015d8bed2b2c040f device

    root on debian Sun Nov 10 22:33
    [~]# adb reboot-bootloader
    root on debian Sun Nov 10 22:34
    [~]# fastboot boot zImage-3.1.10-tk3+
    creating boot image…
    creating boot image – 5632000 bytes
    downloading ‘boot.img’…
    OKAY [ 0.851s]
    booting…
    OKAY [ 0.184s]
    finished. total time: 1.035s
    root on debian Sun Nov 10 22:34
    [~]#

    Any ideas?

    Thanks, Sjef.

    Reply
    • November 11, 2013 at 9:12 am
      Permalink

      Since you get DHCP working at least partly it means that the rootfs gets mounted and it actually gets quite far in the booting process.

      You should see kernel printing messages over HDMI even without any rootfs and if that would work, then the debugging of the later issues would be easier.

      What kind of TV or monitor are you using? Can you try with a different one? I’ve tried with a 1080p Sony Bravia and a 22″ LG 1650×1080 monitor and for me they’ve worked.

      Reply
      • November 12, 2013 at 12:45 am
        Permalink

        The change of environment did it !
        I went to another location with another monitor (also 1080p) and another host (Raspberry Pi) and it worked. Now I’m not sure which one to blame.
        SSH also no problem anymore.

        I got Crashplan working, a Java processor/memory “hog” which underperformed on my Raspberry and DS212+ NAS, in order to test how it performs on the 4core Ouya.

        Thanks !

        Reply
  • November 11, 2013 at 3:42 pm
    Permalink

    Can’t reply to Jake as the depth limit is too small..

    Anyway, Jake, I’m not going to make an Ubuntu image and share that, mostly because I’m using Debian and I don’t have a place to upload it. But I’m hoping there are others interested in tinkering with Ubuntu on Ouya and that somebody will eventually share a basic Ubuntu image.

    Reply
    • November 11, 2013 at 6:56 pm
      Permalink

      Thanks for your consideration, I’ll give it another shot on the weekend. Hopefully I can get through your steps… I’ll search around for a crash course on commands and anything else I might need basic knowledge of.

      Reply
    • November 13, 2013 at 9:32 pm
      Permalink

      Nice! I’ll test it during the weekend :)

      Reply
    • November 13, 2013 at 10:56 pm
      Permalink

      I think this is what I’ve been looking for! You’re a legend, thank you so much! I will get back to you with my results when I get round to trying this. Thanks again!

      Reply
    • November 20, 2013 at 6:55 am
      Permalink

      I tried this and it doesn’t work for me… the screen just stays black. It MIGHT be the video mode – what resolution is the image set for by default? My 32″ LCD HDTV cannot handle 1080p. I run the OUYA in 720p. If the linux image starts at 1080p, I’d not be able to see anything.

      Reply
      • November 20, 2013 at 8:45 am
        Permalink

        Kernel should pick the mode that the TV suggests, so 720p should work just fine. Although I’ve only tested 1920×1080 on my TV and 1680×1050 on my monitor.

        Reply
        • November 21, 2013 at 9:15 pm
          Permalink

          I don’t think the boot is getting that far – I checked the USB stick, and none of the dates got touched. The latest date was like Nov 6. So I think it’s failing before mounting the stick. The boot script say that the Ouya is detected, it reboots, and the script then says the bootloader is detected… and then nothing. I’m sooooooo close!

          Reply
          • November 21, 2013 at 9:35 pm
            Permalink

            Unfortunately I don’t have more hints. Testing with another TV or monitor could be the easiest thing.

            Reply
          • November 22, 2013 at 11:23 am
            Permalink

            Joe, I think you are right, the kernel hasn’t started yet. When the “bootloader detected” is displayed the fastboot tool should attepmt to upload the kernel to ouya and you should see in your terminal a message the kernel is being uploaded. If you cannot see the message then try to open another terminal and run the fastboot manually: fastboot boot zImage.

            Reply
          • November 29, 2013 at 12:28 am
            Permalink

            I got it to boot with fastboot (for me, I had to get the one featured on XDA, the SDK version didn’t work for me), then it had a load of white text, then the Xubuntu logo popped up with the loading ‘dots’. It never got past that stage, even after an hour! :( I’ll try again tomorrow.

            Reply
          • November 29, 2013 at 1:53 am
            Permalink

            xubuntu with dots… I’ve seen it a few times if network is not configured (not always though). Press ctrl+c and it will go away to the login screen. Once the network is configured it should not pop up next time.

            Reply
  • November 22, 2013 at 7:34 pm
    Permalink

    Any progress on running xbmc? I take it I need to compile xbmc and enable tegra so it will run?

    Any help is appreciated, I’m not concerned about gstreamer decoding, I would just like to see it running.

    Cheers
    Stevie

    Reply
    • November 22, 2013 at 9:09 pm
      Permalink

      Unfortunately I haven’t spent more time on it. For XBMC somebody would need to try out the Tegra’s OpenMAX support as XBMX doesn’t support GStreamer.

      Reply
  • November 23, 2013 at 2:13 pm
    Permalink

    Any windows instructions?

    Reply
    • November 24, 2013 at 11:37 am
      Permalink

      Unfortunately I don’t have any windows instructions. The Android ADB/fastboot tools should be available on windows as well and at least using the Ubuntu 12.04 LTS image meantioned earlier it should be possible.

      Reply
  • November 24, 2013 at 2:23 pm
    Permalink

    Looks like I gave some testing to do tomorrow… Also if you want XBMC just go get the latest android nightly and sideload it… under settings (advanced) disable libfright..or something like that… And it works flawless even on 1080p mkv with dts

    Reply
  • November 30, 2013 at 4:26 am
    Permalink

    Thanks for sharing this, Tuomas. I used Ubuntu 13.04 64bit as the host therefore there were some adjustments I had to make in order to get the guide through:
    1) my default shell is zsh which causes “/bin/bash not found” error while doing the chroot step, therefore the shell needs to be changed to /bin/bash, log out, log back in before starting any step
    2) both android-tools-adb and android-tools-fastboot are avaialbe in the ubuntu repo, simply install them by apt-get install (had to removed the package installed by sudo dpkg -i android-tools*deb, wasn’t able to find ouya from the device list using the deb version)
    3) had to use sudo fastboot boot zImage-3.1.10-tk* to boot into debian, without sudo I kept getting “waiting for device” message, and ouya runs in a booting loop (without any output).

    Hope the above helps those use a similar system to make the usb stick.

    Reply
  • November 30, 2013 at 2:07 pm
    Permalink

    I need to know: can this run Steam games that support Linux? If so, the OUYA’s capabilities may be tapped at last.

    Reply
    • November 30, 2013 at 2:15 pm
      Permalink

      Steam games are all x86 games, so Intel compatible hardware only. Ouya is ARM so it can only run games compiled for ARM architecture. Also they are in completely different performance levels.

      Reply
  • December 5, 2013 at 11:37 pm
    Permalink

    What you did there is very very impressive.
    I would love to see a completely flashable Img, that would completely replace the Ouya OS.
    I’ll get myself a Raspberry Pi for christmas, but that’s for a little SSH server I’m going to store my university projects on (since my university only allows 200mb of permanent backed up storage on their servers).
    But I’d really like to see a fully working Linux on Ouya, as I could use that as a good portable solution.
    Sadly I will get OS development in my 3rd semester of computer science and I just started out, so I basically lack the knowledge to do something like that myself.

    Reply
  • January 3, 2014 at 5:25 pm
    Permalink

    Hello there,

    I tried your steps, and got some problems.

    First, when I log in into Debian (on the OUYA), it seems that there are no icons. Don’t know if this was my fault, apt-get’s fault, or anything else.

    Also, when I tried to play a video, it was really slow, and the sound was really low/bass (as you’d expect from a sound that was slowed down)… don’t know what happened.

    And… could you explain how to get the wifi working? I copied the driver from the OUYA (it seems there is a new version of it on the last firmware update), but don’t know how to proceed.

    I’d also like to thank you for your efforts on making this possible. :)

    Reply
    • January 3, 2014 at 8:47 pm
      Permalink

      What icons are you referring to?

      Did you try the video with Totem after selecting the video sink with “gconftool-2 -s /system/gstreamer/0.10/default/videosink nvxvimagesink –type=string”? I had the same audio problem but it got fixed with the proper /etc/asound.conf that should installed with the debian package of mine.

      The wifi should work after copying the two files from the Android filesystem as stated in the instructions. You probably need to restart after that so that the firmware files are in place when the startup script tries to load the wifi kernel module. “lsmod” should show all the loaded modules. If it’s not loaded automatically, you can load it with “sudo modprobe bcmdhd”. After that the NetworkManager should detect it.

      Reply
    • January 13, 2014 at 2:08 pm
      Permalink

      GStreamer on Tegra is using OMX as the backend so trying that OMX version of Mplayer would definitely be an interesting project. Any takers? :)

      Reply
  • January 15, 2014 at 5:17 pm
    Permalink

    Hi, Tuomas.

    First of all, thanks for your awesome manual. I’ve installed Ubuntu 13.10 (Saucy) in my Ouya and everything seems to work fine. :)

    I’ve investigated why hciconfig doesn’t show the BT adapter and found the answer in a script in the OUYA’s internal memory: [mmcblk0p3]/bin/bt_firmware_loader.sh
    [...]
    brcm_patchram_plus --enable_hci --use_baudrate_for_download --scopcm=0,2,0,0,0,0,0,0,0,0 --baudrate 3000000 --patchram /lib/firmware/bcm4330/bcm4330.hcd --no2bytes --enable_lpm --tosleep=50000 /dev/ttyHS2 > /dev/null &
    [...]

    After executing this command, hciconfig shows the integrated BT adapter as “hci0″ and now I can pair a BT device, like OUYA controllers. Maybe it’s not the best way, but it works. If someone knows a better way to load the BT adapter, please correct me. :)

    I have one question: how did you created the zImage? I would like to create a new image with an updated kernel version and customize some things.

    Reply
    • January 15, 2014 at 6:34 pm
      Permalink

      I’m glad to hear that!

      Did you need to do some changes when following my instructions? Did you use the same login manager? I had some graphical issues with it.

      I believe that brcm_patchram_plus is needed always to get the BT running. Something similar is included in the L4T reference system and I did try it but didn’t get the hcio to appear. I assume you copied the BT and WiFi firmwares from the Android system? I’ll add that command to the instructions. Getting Mame running with Debian on Ouya might be nice :) (Although I’m not sure if it can use any acceleration and graphical perf might not be good enough.

      The zImage is just a normal compressed kernel image that you create with “make ARCH=arm CROSS_COMPILE=/path/to/your/compiler/bin/arm-none-linux-gnueabi- zImage”.

      Reply
      • January 15, 2014 at 10:59 pm
        Permalink

        Right now, I’m using the Ouya as download center without graphical enviroment. During my installation tests I don’t remember having any issue with Slim and Xfce, but maybe I haven’t tested enough.

        Yes, the Wifi and BT firmware (bcm4330.hcd) was copied from the Android system, following your instructions for the Wifi adapter. I added the brcm_patchram_plus command to the rc.local script (for example) to get BT working after each reboot.

        Woh, getting Mame working would be awesome! :)

        Reply
        • January 19, 2014 at 11:27 pm
          Permalink

          Mame didn’t work for me from the official deb packages. It seems to me the build depends on OpenGL which is not supported. Mame would have to be recompiled not to use OpenGL which should be in theory possible by specifying NO_OPENGL = 1 in the /src/osd/sdl/sdl.mak

          Reply
        • February 9, 2014 at 3:50 pm
          Permalink

          I’ve recompiled latest mame version against sdl2 backend. that version didn’t work. crashed on sigsegv in the delegate.c source. I also took an older mame version (1.25) and created a new backend running on gles2 and alsa. that one runs quite well. i’m still working on few bits (usb joystick support, shaders), but plan to release it soon.

          Reply
          • February 9, 2014 at 5:29 pm
            Permalink

            Sounds cool! Do let us know when you have updates :)

            Reply
            • March 23, 2014 at 2:15 pm
              Permalink

              I increased the reply depth to 10, so now I can reply :)

              Nice work with the Mame. I quickly tested that it starts on my 13.04 too.

              Why no support for Ouya’s own pad?

              Somebody here mentioned that the BT was easy to get working but I still didn’t succeed on it, at least on the 13.04.

              Reply
            • March 23, 2014 at 4:56 pm
              Permalink

              Thanks. No BT so far as I was lazy to dig into that. Another dicouragement for me is the fact I don’t like the OUYA controller, all buttons are too hard to press, so I prefer using PS3 joypads instead. For arcade games I use Hori FS3 wireless joystick.
              Maybe somebody else could have a look, figure out how to pair the OUYA controller in linux and check whether it can be accessed via /dev/input/jsX device. Once that is done mame should work with the pad without modifications (maybe some button remapping will have to altered in joy.map file).

              Reply
  • February 9, 2014 at 7:47 am
    Permalink

    Hi Tuomas,

    the kernel does not shedule on more than one cpu-core. Do you notice?
    Top show only 100% cpu load in total, but it should got to 400% for a 4-core machine.
    Any idea to for a fix. Which toolchain doe you use for bulding the kernel image? Any fixes used?

    Kind regards

    Reply
    • February 9, 2014 at 9:55 am
      Permalink

      I think it was using four cores for me. What are you using to generate CPU load? You need to use four application instances or an application that uses four threads.

      The toolchain might have been 2010.09-50 from Code Sourcery, I’m not sure anymore. I didn’t modify the toolchain in anyway and the fixes I had for the kernel are in my github source tree.

      Reply
    • February 9, 2014 at 3:37 pm
      Permalink

      all 4 cores are enabled. press key 1 when running top to show all core stats.

      Reply
  • February 9, 2014 at 4:47 pm
    Permalink

    Thanks a lot for your work. I installed Ubuntu 12.04 on my Ouya these days. It works. But I am not yet 100% satisfied with the possibilities of a media center.

    And I made a mistake and perhaps someone of you can help me. I wanted to install my Ubuntu as a dual boot, but unfortunately I installed the zImage into LNX of ouya (instead of the DualBoot Kernel). The boot process to the Ubuntu works, but I can’t access my Ouya anymore. And the Android Recovery Console is not working either (cause the Linux is running).
    Is there any possibility to recover the LNX record? Or do I have now a Linux Computer with limited functionality (without working XBMC)?

    Thanks in advance.

    Reply
      • February 9, 2014 at 5:28 pm
        Permalink

        I think you can flash those partitions from linux as well. But if you now break the linux and wouldn’t have anything booting, then you might be in trouble.

        Unfortunately I don’t know much about those bootloaders as so far I haven’t touched the internal flash.

        I think you should search the xda-developers forum, there’s hopefully some hints. Or try asking in the Ouya thread in there.

        Reply
      • February 10, 2014 at 3:32 pm
        Permalink

        if I understand it well you boot straight into the linux, right? in theory it should be enough to owerwrite the LNX partition with the dual boot kernel (to give you dual boot options at the startup) or with your backup of the lnx partition (to boot straight to android). I don’t know how to write to the lnx partition from linux environment though.

        Reply
      • February 11, 2014 at 12:30 am
        Permalink

        I had a look at the partitions and the lnx partition on my ouya is /dev/mmcblk0p2. how did I find out? I used “dd” to copy it to my memory stick and then used “cmp” to compare it with boot102513.img which is the dual boot kernel I flashed last year. the both files matched in size and content. I think the fix is obvious. hope it helps.

        Reply
        • February 11, 2014 at 11:59 pm
          Permalink

          Thanks for your research, its a very good approach, I didn’t thought about this.

          Unfortunately, they are not exactly the same. One Byte is different (the first one). I don’t know how tremendous this is, my experiences with kernels are long time ago. But since it is the kernel and you can easy brick the Ouya, I am very careful, even if it looks like, that the first bytes are only the description (ANDROID!)


          root@ouya:/dev/block# dd if=/dev/mmcblk0p2 of=/tmp/mmcblk0p2
          16384+0 records in
          16384+0 records out
          8388608 bytes (8.4 MB) copied, 0.393623 s, 21.3 MB/s
          root@ouya:/dev/block# cmp /tmp/mmcblk0p2 /tmp/zImage
          /tmp/mmcblk0p2 /tmp/zImage differ: byte 1, line 1
          root@ouya:/dev/block# dd count=100 bs=1 if=/dev/mmcblk0p2
          ANDROID!��O� �\ 100+0 records in
          100+0 records out
          100 bytes (100 B) copied, 0.00745647 s, 13.4 kB/s
          root@ouya:/dev/block# dd count=100 bs=1 if=/tmp/zImage
          �����������������(o��Op����� ����V4� �� ���!��G��100+0 records in
          100+0 records out
          100 bytes (100 B) copied, 0.00541793 s, 18.5 kB/s

          Reply
        • February 12, 2014 at 12:37 am
          Permalink

          Sorry. In the rush I made 2 mistakes. You are right, it is /dev/mmcblk0p2!

          I compared it with the wrong kernel image (there was a lot of confusion, when I tried to restore the kernel) and the dd of /dev/mmcblk0p2 was bigger than the kernel, so there was more information from an older kernel.

          Thanks for your help! I am very happy now!

          root@ouya:/tmp/kernel# dd if=/dev/mmcblk0p2 of=/tmp/kernel/mmcblk0p2
          16384+0 records in
          16384+0 records out
          8388608 bytes (8.4 MB) copied, 0.332686 s, 25.2 MB/s
          root@ouya:/tmp/kernel# ll
          total 13400
          drwxr-xr-x 2 root root 80 Feb 11 22:33 ./
          drwxrwxrwt 9 root root 420 Feb 11 22:33 ../
          -rw-r--r-- 1 root root 5330944 Feb 11 22:20 kernelA1.img
          -rw-r--r-- 1 root root 8388608 Feb 11 22:32 mmcblk0p2
          root@ouya:/tmp/kernel# dd count=5330944 bs=1 if=/tmp/kernel/mmcblk0p2 of=/tmp/kernel/mmcblk0p2_resized
          5330944+0 records in
          5330944+0 records out
          5330944 bytes (5.3 MB) copied, 20.387 s, 261 kB/s
          root@ouya:/tmp/kernel# ll
          total 18608
          drwxr-xr-x 2 root root 100 Feb 11 22:33 ./
          drwxrwxrwt 9 root root 420 Feb 11 22:33 ../
          -rw-r--r-- 1 root root 5330944 Feb 11 22:20 kernelA1.img
          -rw-r--r-- 1 root root 8388608 Feb 11 22:32 mmcblk0p2
          -rw-r--r-- 1 root root 5330944 Feb 11 22:34 mmcblk0p2_resized
          root@ouya:/tmp/kernel# cmp kernelA1.img mmcblk0p2_resized
          root@ouya:/tmp/kernel# md5sum mmcblk0p2_resized
          7549fc33869041dba785b2ee48625c18 mmcblk0p2_resized
          root@ouya:/tmp/kernel# md5sum kernelA1.img
          7549fc33869041dba785b2ee48625c18 kernelA1.img

          Reply
  • February 10, 2014 at 12:00 pm
    Permalink

    Hi Tuomas,

    i checked again and now i’ll think it is a problem with network traffic, not multicore related.
    I just do “root@ouya:/run/shm# wget http://cdimage.debian.org/debian-cd/7.4.0/amd64/iso-cd/debian-7.4.0-amd64-CD-1.iso” and get a lot of:

    [134075.903997] kswapd0: page allocation failure: order:3, mode:0×20
    [134075.917783] [] (unwind_backtrace+0×0/0×144) from [] (dump_stack+0×20/0×24)
    [134075.940864] [] (dump_stack+0×20/0×24) from [] (warn_alloc_failed+0xcc/0x11c)
    [134075.964135] [] (warn_alloc_failed+0xcc/0x11c) from [] (__alloc_pages_nodemask+0×504/0×704)
    [134075.989051] [] (__alloc_pages_nodemask+0×504/0×704) from [] (kmem_getpages.clone.39+0x3c/0×128)
    [134076.014318] [] (kmem_getpages.clone.39+0x3c/0×128) from [] (cache_grow.clone.36+0x8c/0x29c)
    [134076.039250] [] (cache_grow.clone.36+0x8c/0x29c) from [] (cache_alloc_refill+0x36c/0x3a8)
    [134076.063857] [] (cache_alloc_refill+0x36c/0x3a8) from [] (__kmalloc_track_caller+0x1b0/0x1bc)
    [134076.089303] [] (__kmalloc_track_caller+0x1b0/0x1bc) from [] (__alloc_skb+0×64/0xf0)
    [134076.113893] [] (__alloc_skb+0×64/0xf0) from [] (__netdev_alloc_skb+0x2c/0×54)
    [134076.138469] [] (__netdev_alloc_skb+0x2c/0×54) from [] (rx_submit+0×30/0x33c)
    [134076.163249] [] (rx_submit+0×30/0x33c) from [] (rx_complete+0x2b8/0×358)
    [134076.188374] [] (rx_complete+0x2b8/0×358) from [] (usb_hcd_giveback_urb+0×60/0xd0)
    [134076.215145] [] (usb_hcd_giveback_urb+0×60/0xd0) from [] (ehci_urb_done+0xa0/0xb4)
    [134076.242946] [] (ehci_urb_done+0xa0/0xb4) from [] (qh_completions+0x2a4/0×494)
    [134076.271120] [] (qh_completions+0x2a4/0×494) from [] (scan_async+0xb0/0×198)
    [134076.299317] [] (scan_async+0xb0/0×198) from [] (ehci_work+0×40/0x9c)
    [134076.326865] [] (ehci_work+0×40/0x9c) from [] (ehci_irq+0x3a0/0x5e8)
    [134076.354290] [] (ehci_irq+0x3a0/0x5e8) from [] (tegra_ehci_irq+0×64/0xc8)
    [134076.382214] [] (tegra_ehci_irq+0×64/0xc8) from [] (usb_hcd_irq+0×44/0×94)
    [134076.410258] [] (usb_hcd_irq+0×44/0×94) from [] (handle_irq_event_percpu+0×74/0×290)
    [134076.439225] [] (handle_irq_event_percpu+0×74/0×290) from [] (handle_irq_event+0x4c/0x6c)
    [134076.468551] [] (handle_irq_event+0x4c/0x6c) from [] (handle_fasteoi_irq+0xac/0×150)
    [134076.497472] [] (handle_fasteoi_irq+0xac/0×150) from [] (generic_handle_irq+0x3c/0x4c)
    [134076.526525] [] (generic_handle_irq+0x3c/0x4c) from [] (handle_IRQ+0×68/0xbc)
    [134076.554918] [] (handle_IRQ+0×68/0xbc) from [] (asm_do_IRQ+0×18/0x1c)
    [134076.582424] [] (asm_do_IRQ+0×18/0x1c) from [] (__irq_svc+0×38/0xd0)
    [134076.609842] Exception stack(0xe678dab8 to 0xe678db00)
    [134076.624698] daa0: ef926d2c a0000113
    [134076.651741] dac0: 00000000 00000002 ef926c60 eaf23f60 e54d70e0 ef926d2c a0000113 00000000
    [134076.678377] dae0: e54d70f8 e678db0c e678db10 e678db00 c040f5d8 c0796e34 60000113 ffffffff
    [134076.705064] [] (__irq_svc+0×38/0xd0) from [] (_raw_spin_unlock_irqrestore+0x2c/0×58)
    [134076.733122] [] (_raw_spin_unlock_irqrestore+0x2c/0×58) from [] (rx_submit+0×238/0x33c)
    [134076.761412] [] (rx_submit+0×238/0x33c) from [] (usbnet_bh+0x3f0/0×530)
    [134076.788294] [] (usbnet_bh+0x3f0/0×530) from [] (tasklet_action+0xac/0x1bc)
    [134076.815351] [] (tasklet_action+0xac/0x1bc) from [] (__do_softirq+0×110/0×264)
    [134076.842834] [] (__do_softirq+0×110/0×264) from [] (irq_exit+0xac/0xb0)
    [134076.869608] [] (irq_exit+0xac/0xb0) from [] (handle_IRQ+0x6c/0xbc)
    [134076.895990] [] (handle_IRQ+0x6c/0xbc) from [] (asm_do_IRQ+0×18/0x1c)
    [134076.922373] [] (asm_do_IRQ+0×18/0x1c) from [] (__irq_svc+0×38/0xd0)
    [134076.948885] Exception stack(0xe678dc58 to 0xe678dca0)
    [134076.963197] dc40: 000000ba 0000001f
    [134076.989342] dc60: 00000000 0000009b c123c0d4 c0af59c0 00c21000 c17169c0 00c21000 80000013
    [134077.015309] dc80: 002e95c6 e678dcd4 e678c020 e678dca0 c01044c8 c0105034 60000013 ffffffff
    [134077.041620] [] (__irq_svc+0×38/0xd0) from [] (free_hot_cold_page+0×190/0x1f4)
    [134077.068948] [] (free_hot_cold_page+0×190/0x1f4) from [] (__pagevec_free+0×68/0xf0)
    [134077.096822] [] (__pagevec_free+0×68/0xf0) from [] (free_page_list+0xac/0xec)
    [134077.124165] [] (free_page_list+0xac/0xec) from [] (shrink_page_list+0×508/0x6c0)
    [134077.151948] [] (shrink_page_list+0×508/0x6c0) from [] (shrink_inactive_list+0x12c/0x4b4)
    [134077.180447] [] (shrink_inactive_list+0x12c/0x4b4) from [] (shrink_zone+0x2f8/0x3b4)
    [134077.208552] [] (shrink_zone+0x2f8/0x3b4) from [] (balance_pgdat+0×950/0xb74)
    [134077.235842] [] (balance_pgdat+0×950/0xb74) from [] (kswapd+0×144/0×208)
    [134077.262759] [] (kswapd+0×144/0×208) from [] (kthread+0xb0/0xb4)
    [134077.289014] [] (kthread+0xb0/0xb4) from [] (kernel_thread_exit+0×0/0×8)
    [134077.315852] Mem-info:
    [134077.327109] Normal per-cpu:
    [134077.338686] CPU 0: hi: 186, btch: 31 usd: 155
    [134077.352493] CPU 1: hi: 186, btch: 31 usd: 192
    [134077.366012] CPU 2: hi: 186, btch: 31 usd: 34
    [134077.379385] CPU 3: hi: 186, btch: 31 usd: 36
    [134077.392620] HighMem per-cpu:
    [134077.403633] CPU 0: hi: 90, btch: 15 usd: 86
    [134077.416564] CPU 1: hi: 90, btch: 15 usd: 89
    [134077.429170] CPU 2: hi: 90, btch: 15 usd: 91
    [134077.441175] CPU 3: hi: 90, btch: 15 usd: 76
    [134077.452662] active_anon:6877 inactive_anon:9487 isolated_anon:0
    [134077.452672] active_file:93206 inactive_file:99141 isolated_file:33
    [134077.452682] unevictable:0 dirty:118 writeback:414 unstable:0
    [134077.452691] free:23179 slab_reclaimable:7028 slab_unreclaimable:3517
    [134077.452701] mapped:1428 shmem:6 pagetables:136 bounce:0
    [134077.514454] Normal free:92276kB min:3528kB low:4408kB high:5292kB active_anon:20344kB inactive_anon:30680kB active_file:266192kB inactive_file:288536kB unevictable:0kB isolated(anon):0kB isolated(file):132kB present:779520kB mlocked:0kB dirty:320kB writeback:1088kB mapped:5296kB shmem:20kB slab_reclaimable:28112kB slab_unreclaimable:14068kB kernel_stack:840kB pagetables:544kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
    [134077.591248] lowmem_reserve[]: 0 1806 1806
    [134077.601827] HighMem free:440kB min:224kB low:484kB high:744kB active_anon:7164kB inactive_anon:7268kB active_file:106632kB inactive_file:108028kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:231184kB mlocked:0kB dirty:152kB writeback:568kB mapped:416kB shmem:4kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:7 all_unreclaimable? no
    [134077.676024] lowmem_reserve[]: 0 0 0
    [134077.686065] Normal: 6312*4kB 5996*8kB 1191*16kB 0*32kB 0*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 92400kB
    [134077.711485] HighMem: 110*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 440kB
    [134077.736920] 193086 total pagecache pages
    [134077.747786] 730 pages in swap cache
    [134077.758222] Swap cache stats: add 10808, delete 10078, find 4695/5369
    [134077.771766] Free swap = 517868kB
    [134077.782350] Total swap = 524284kB
    [134077.848898] 261632 pages of RAM
    [134077.859301] 24164 free pages
    [134077.869324] 15849 reserved pages
    [134077.879699] 10568 slab pages
    [134077.889406] 187788 pages shared
    [134077.899353] 730 pages swap cached
    [134077.909414] smsc95xx 1-1:1.0: eth0: kevent 2 may have been dropped

    Reply
    • February 10, 2014 at 12:08 pm
      Permalink

      Why are you downloading it to /run/shm? You are downloading it to memory and to me it looks like you are running out of it.

      Ouya has 1GB of RAM and you are trying spend 623MB of RAM by downloading an ISO image to RAM.

      Reply
      • February 10, 2014 at 12:41 pm
        Permalink

        I download to mem to see it is clearly a network problem. And to see its not a usb problem.
        Seen the issue after a few seconds aprox. 5MB of downloading. No running out of mem issue. Same happens for write to file.

        Reply
  • February 20, 2014 at 1:51 am
    Permalink

    Hey just wondering how development is going? The ouya stock with android is pretty crap for xbmc with large collections and movies. Constant buffering or dropouts when watching movies whilst scanning or just watching movies…

    Reply
    • February 20, 2014 at 9:45 am
      Permalink

      From my part the development is pretty much done. People are able to run both Debian and Ubuntu on Ouya.

      Unfortunately I am not aware of any projects working with XBMC on Debian on Ouya.

      Reply
  • March 16, 2014 at 7:48 pm
    Permalink

    Thanks for all the work on this, I’ve used it as an excellent starting point to get Ubuntu installed and working on my Ouya. However, I was wondering what source you used for the kernel, and if you had to do anything special outside of setting up a config file to get it to compile. I’ve been trying to compile my own from the source Ouya has up on github, but for the life of me I can’t get it to compile with a working framebuffer, even when I use your config file with all the same cmdline options.

    Reply
  • May 22, 2014 at 1:44 am
    Permalink

    This is brilliant work, Though I do have a question. does this remove the default OS from the ouya? Or is this like a sort of dual-boot?

    Reply
    • May 22, 2014 at 2:51 am
      Permalink

      ah, never mind, after actually looking at it, I can see this is booted through the RAM, not even touching the default OS. Though, I’m curious, shouldn’t it be fairly simple past this point to create an installer that can automatically create the files needed for this to work? a good way to idiot proof the process.

      Reply
      • May 22, 2014 at 4:59 pm
        Permalink

        The easiest way would be to provide ready Ubuntu images but I didn’t want to do that as there are still risks involved.

        Somebody did provide some image already though earlier in the comments.

        Reply
  • June 15, 2014 at 11:28 pm
    Permalink

    Hello. I am a noob, but i would love to have Ubuntu on my ouya. is there a easy way to install it ? Sorry for my bad english.
    Mads. :)

    Reply
    • June 16, 2014 at 6:01 am
      Permalink

      Did you check the instructions in the Github? I think they are quite straightforward. I don’t want to make it too easy as Ouya doesn’t have a proper recovery mechanism.

      Reply
  • October 25, 2014 at 9:10 am
    Permalink

    Hi Tuomas.

    Quite long not posting here :)…

    I’ve been running debian on the Ouya for more than a year, and the more “things” I run in this piece of hardware, the more impresive I think it is. I have the module flashed in the ouya to for it to be able to load the kernel from the internel flash memory and that was quite a big achievement… well now the question/doubt :)…

    I’m trying to mount some external NFS mountpoint and I think that this nfs module is (NFS transport layer) not supported by the kernel you built (I guess).

    Can you provide some information about how to build the kernel fot the ouya to build as much modules as possible? I guess that would provide additional flexibility to the “little machine” we have.

    Thanks and keep up bringing us new things supported by nVidia Tegra3/4/TK1.

    Best regards.

    juisjuis.

    Reply
    • October 25, 2014 at 9:31 am
      Permalink

      Cross compiling kernels is quite easy. First you need a cross compiler. I use Linaro toolchain mostly because Debian Stable doesn’t provide cross compilers. Ubuntu does, so on Ubuntu this is probably enough:


      sudo apt-get install crossbuild-essential-armhf

      The Linaro toolchain you can get from there:
      http://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux.tar.xz

      You can extract it to any directory and use without any further installing or setup.

      Get the kernel sources from my Github, either with git clone if you want to track your changes or as a .tgz without the huge git history if you just want to try changing one option. Extract the sources.

      Apply the default config in the kernel source tree (if using Ubuntu’s cross compiler, skip the path for the toolchain as it’s already in the path):

      make ARCH=arm CROSS_COMPILE=/path/to/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- ouya_linux_defconfig

      You probably should edit .config and change CONFIG_LOCALVERSION for each kernel so that you can switch between them conveniently without touching the modules. You can also change the LOCALVERSION in the menuconfig phase below.

      Then you can make your own changes to the config:

      make ARCH=arm CROSS_COMPILE=/path/to/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- menuconfig

      And compile:

      make ARCH=arm CROSS_COMPILE=/path/to/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- zImage modules -j4

      Install modules to a temporary location:

      make ARCH=arm CROSS_COMPILE=/path/to/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf- INSTALL_MOD_PATH=/tmp/ouya

      Now you need to copy the modules from /tmp/ouya/lib/modules/ to Ouya. Do note that there is links to the source directory and simple "scp -r" will follow the link and copy your whole source tree as well. So remove the links first. Or create a tar ball and copy that.

      The new zImage is in arch/arm/boot/zImage.

      The modules might not work after the first boot and in that case you need to run "sudo depmod -a" on Ouya. Because of that make sure all the drivers needed to boot up is included in the kernel and not as modules.

      EDIT: About your question related to NFS, it looks like the basic NFS support is included but not the newer v3 and v4 versions. Try enabling those first. Run "cat /proc/filesystems" on Ouya to see what filesystems it currently supports.

      Reply
  • October 30, 2014 at 10:13 pm
    Permalink

    Hi Tuomas.

    Kernel compiled after some fighting… thx for the help, since my old Slackware days :) I didn’t compile the kernel, so it has been quite a while.

    Now I have my kernel/modules in the Ouya and…
    —-
    [ 7.682165] EXT4-fs (mmcblk0p9): recovery complete
    [ 7.691169] EXT4-fs (mmcblk0p9): mounted filesystem with ordered data mode. Opts: (null)
    [ 7.708633] VFS: Mounted root (ext4 filesystem) on device 179:9.
    —-
    If you see above, I managed to create a huge tarball with the whole operating system and dump it into the /dev/mmcblk0p9 device, which is the Ouya Android OS data partition, :) Now ouya runs autonomously 100% without any USB.

    I just set the kernel into the /dev/mmcblk0p3 which is the Ouya Android /system partition… so with the multi bootloader from xda_developpers http://forum.xda-developers.com/showthread.php?t=2450711 and some imagination, we can have the Debian/Ubuntu installed into the ouya, runing based on its own flash memory.

    Best regards.

    juisjuis.

    Reply
    • November 1, 2014 at 10:13 am
      Permalink

      So now theEXT4 based mmcblk0p9 is both the Android data partition and the Linux rootfs? Nice work :)

      Reply
      • November 3, 2014 at 9:23 am
        Permalink

        Hi Tuomas.

        No, the mmcblk0p9 content was deleted 100% and reformated to ext4. No fingerprint of the Android data “data files”. That partition is now a pure debian root.

        The boot loader from xda-devs that I pointed out in the previos post looks in the following partitions for the kernel to load:
        1.-sdcard “android folder” folder in the mmcblk0p9
        2.-/system folder in the mmcblk0p3

        Based on that fallback to /system folder , I decided to get rid of the data “data files” based on mmcblk0p9 partition and pt my kernels into the /system folder.

        Improvement from this:
        I could see that the time that the processes wait for the USB access, to access the filesystem has almost dissapeared (the “wa%” present in “top” command).

        So the ouya is doing really great running on the internal flash. Moreover, if someone wants to revert all of this to have an ouya “configuraed as it came from the dealer”. The OTA loading is still available in the recovering prtition so an standard ouya android OS can be flashed again.

        Tuomas, Do you think it would be worthy to build a guide to implement all of this?

        juisjuis.

        Reply
        • November 4, 2014 at 12:06 pm
          Permalink

          Well, I think writing a guide would be much less work than what you have already put to it, so yes, it probably would be worth it :)

          It’s also possible that when Ouya starts to get old for its original use case, more people might want to try using it for other stuff.

          Reply
  • December 16, 2014 at 3:20 am
    Permalink

    Today was my last day at uni (well, art school, but splitting hairs :). juisjuis – a readme.md would be amazing. I went ahead and bought an extra controller when I first backed OUYA (ugh clicky-clack) and abandoned my transformation into “*” dreams because of how sluggish it was to run apps outside of native Linux and regardless of speed of USB stick I ran into problems there too. I’d love to get MAME (specifically Neo-Geo) titles up and running with the native controllers (so I don’t care if kids break them during Winter break) and then my own projects after the holidays. Please break open that mind of yours onto a howto!

    Reply
  • December 19, 2014 at 9:01 am
    Permalink

    You mentioned you set up this project for h.264 encoding. Could you talk a little bit more about that? I’m slowly converting all my movies into h.264 to throw on a nas and I would love a lower powered solution than what I’m using now. Software used, speed, limitations, etc? Thanx

    Reply
    • December 19, 2014 at 9:51 am
      Permalink

      Well, encoding and decoding are quite different things. I was using Ouya for encoding a h264 video from a webcam and streaming it over a network in my robotic project. But now I’ve moved to Jetson (Tegra K1) for that.

      For decoding one of the most popular apps is Kodi (XBMC). It can be built quite easily with full acceleration for Ouya as well. See this post:

      http://tuomas.kulve.fi/blog/2014/03/24/ubuntu-on-ouya/#comment-1090

      I’m not sure where exactly the limits go but 1080p30 isn’t a problem.

      Reply
      • December 20, 2014 at 2:51 am
        Permalink

        thanx for the quick reply. Maybe I read your post wrong. I thought you were converting already made movie file to h.264. I was just looking for a low power solution to do all the conversion without having to have my power hungry pc on.

        Reply
        • December 20, 2014 at 7:23 am
          Permalink

          Well, you can definitely “transcode” videos as well on Ouya, but the only officially supported HW accelerated multimedia API is GStreamer and I don’t think there popular transcoding apps based on that. With GStreamer it’s quite easy to decode a video file, encode it to h264 and write it back to a file. But usually transcoding apps does e.g. two-pass to better estimate the final size etc. and all that would be much more difficult.

          While you might be able to run something like HandBrake on Ouya, it would be using CPU only and that would be extremely slow.

          Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Why ask?