Ouya is a 99$ Tegra3 based gaming console without a display.
My goal is to use Ouya in my robotics project for video encoding but first I want to have Debian running there with hardware accelerated X.Org, OpenGL ES and video.
I now have the Debian running but with a few bigger issues that I’ll describe shortly. If you want to try it out, you can find my instructions for creating the rootfs in github. That might void the warranty even though the kernel is booted from RAM and the rootfs mounted from USB stick so the Ouya software should remain intact.
Ouya is easily brickable permanently, so you need to be careful not to flash anything there and you’ll be doing it at your own risk.
About the Issues.
HDMI
2013-09-05: HDMI works now with multiple resolutions and is not so picky about having the cable connected already on boot.
Ouya display kernel driver is hardcoded to use HDMI as the primary display with 1920×1080 resolution. That works relatively well as long as you keep your monitor/TV always on. I couldn’t get anything but black if I e.g. switched my monitor to another input and back.
I tried to enable the normal behaviour in the display driver and by disabling the LVDS in xorg.conf but the TV remains black and doesn’t seem to change the resolution. Maybe there is still something hardcoded in the display driver or maybe the driver is trying to enable the non-existent internal panel and gets confused.
Audio
2013-09-11: Got audio working with a simple asound.conf. I also run /etc/init.d/alsa-utils stop but unsure if that affected anything.
aplay -l lists HDMI as the first device and tegrawm8903 as the second. If I make the tegrawm8903 the default the audio plays but only from the left speaker and half the speed.
I don’t know if this is related to the HDMI problems above or if I should just have the correct ALSA mixer configuration.
Video
2013-09-05: Totem has configurable video sink: gconftool-2 -s /system/gstreamer/0.10/default/videosink nvxvimagesink –type=string
Hardware accelerated video decoding and rendering is supported through GStreamer. Currently videos play well with playbin2 as long as the audio is disabled with audio-sink=fakesink and the correct video sink is selected with video-sink=nvximagesink.
Maybe the GStreamer’s autovideosink should be patched to use nvxvimagesink instead of xvimagesink to make nvxvimagesink the default in applications using playbin2
Power
2013-09-05: CPUfreq with ondemand governor is working and enabled in the kernel nby default now.
CPU core hot-plugging works but switching to the low power core seems to lead to a kernel bug (arch/arm/mach-tegra/pm.c:509). Same bug seems to happen with ondemand CPUFreq governor. I haven’t really tried to get those working yet but both of them are working with Nexus7 so maybe it’s possible to get them working on Ouya as well.
If you want to test Debian on Ouya, you can find the needed blobs from my /tmp but I might set up something more appropriate later.
Hi there.
This is great news, if you could run Debian in a non-chroot environment. I guess you are the first one, I suggest you to put your experience into xda-developers site or in the ouya.tv. I guess I would be very apreciated.
Downsides:
It doesn’t work for me with the procedure you put in your Git. I implemented it as you stated in the manual, but I had to fix some things…
1.-export $TARGET=/mnt/rootfs I assume it should be export TARGET=/mnt/rootfs
2.-tar zxf modules-3.1.10-tk1+.tar.gz if you uncompress that file into the “/” it creates the “3.1.10-tk1+” folder in the “/” and I think it should be created in /lib/modules/ not in “/”
I followed the procedure and the only thing I got is a black screen :). Perhaps is because I have a beamer instead of a normal TV (beamer is 1920×1080 capable).
Perhaps the problem is the OTA version I’m running in the Ouya, but if you are able, I would suggest you to put the result of the USB stick creation in tarball format into your Git to be able to put that in the way you created it in a ext4 formated USB stick. Perhaps I made some mistakes (I don’t think so because I repeated the process 3 times).
How can I debug the booting process, do I need some serial console cable?
Cheers.
juisjuis.
Thanks for the comments! I’ve fixed the two bugs in the instructions.
The HDMI output is a bit picky. I get black screen unless the monitor is on with the correct input (HDMI/DVI/VGA) selected when the Ouya tries to access it (right after the fastboot boot command). And if I turn it off or select a different input, it stays black no matter what I try. A reboot is needed to get the image back.
The rootfs is quit big and I don’t really have a place where I could share files of that size.
About debugging. Do you have ethernet cable connected? You should be able to login via ssh even if the monitor stays black, as long as you know the IP address. That way you can use “dmesg” to see the kernel prints during boot and /var/log/XOrg.0.log shows the X.Org logs. I don’t think you can see the debian startup script output though. I didn’t see any errors anywhere when I got the black screen, so seeing all the logs didn’t really help.
You can also use a serial cable but while there’s a place for it on the board, there’s no connector. I did solder cables directly there but that’s a sure way of voiding the warranty. More info about the J3 connector can be found here: http://forums.ouya.tv/discussion/1380/recovery-mode
Hi There.
I guess the problem is more severe, I think my installation doesn’t boot at all.
Or it panic during the bootup or it doesn’t find the partition to mount the rootfs.
I have the DHCP enabled as you stated in the installation process but I don’t see the router assigning any IP address to the Ouya. So I’m afraid that it doesn’t reach execution level 3.
The problem is that I cannot debug anything here. Because there is no output to the TV/Beamer. and I cannot get connected through network, that is why I asked for the tarball.
Can you provide some information about your ouya? I don’t know what are the preconditions you use in yours.
Ist it stock state?
Version of stock firmware?
etc.
The manual looks impressive and I’ve been looking for this for some time and I tell you that you are the first as far as Google knows :).
For me the biggest problem is the inability to debug, because I don’t see what is going on during the bootup.
I got another question, Why you set in the /etc/fstab the root partition as /dev/root? is that the device that the Ouya assigns to the USB? Is it where the zImage tries to link the bootup to?
Thanks for your time.
juisjuis.
I’ve actually installed CWM to Ouya some time ago. There has been several Ouya firmware updates since then so I don’t know what’s the state of that now. I was assuming that the Ouya firmware doesn’t matter as I’m booting a different kernel and different rootfs.
I think nowadays the root partition in /etc/fstab doesn’t really matter as it’s already mounted by the kernel. So I’m again assuming that /dev/root is the actual partition that kernel mounted as root.
I’ve hardcoded the root partition in kernel config to be /dev/sda2. /dev/sda1 is reserved for swap, even though the Debian rootfs doesn’t currently enable it automatically. I’m using an SD card in an USB card reader as the rootfs but (again, I’m assuming that) a real USB stick would have the same /dev/sda node.
Even if you would get the monitor working, the current kernel config doesn’t enable text console on the display, so you wouldn’t see the boot there anyway. I think I tried to enable it quickly at some point but failed, so I’ve been using just the serial console. If you know the exact kernel configuration options for that, I can try them out, but that has to wait until next week.
Hi there.
I guess I got it.
I didn’t create any swap partition, because the access to Swap through the USB2 is a bit slow from my point of view (based on Raspberry Pi experience), so I didn’t created that partition, so my root partition would be /dev/sda1 so the kernel looks for it in the wrong place. I will create a very tiny swap partition into the USB memory and I will try today later.
Again thanks for you help and time.
juisjuis.
Yes, swap on a USB stick is definitely slow. But I think Linux likes to have a small amount of swap as it doesn’t handle OOM situations very well (that might be a bit old info though). The swappiness should be set to “don’t too easily” to avoid extra swapping.
But as said, the rootfs doesn’t enable it automatically so I haven’t really used it.
After creating a swap partition as /dev/sdX1 I could launch the Debian installation.
This is really great.
Thx, and keep up with this, is an awesome thing to run a native Debian in the Ouya.
The main thing now would be to be able to boot from the Android system directly with the kernel in the USB on somewhere in the /sdcard folder.
Again thx for your time and help.
juisjuis
Regarding swap…
Add the following line when you create the /etc/fstab file in the installation process.
/dev/sda1 none swap sw 0 0
Thanks, added to README.md
Great work! I haven’t had time to try this yet, but I’ve been looking forward to running Debian (or Ubuntu) on the Ouya since it was announced! Anyways, keep up the good work!
Thanks. Now I just need to find somebody who knows something about ALSA configurations.
HDMI video is now working better but ALSA is not. I found asound.conf from the Android rootfs but I’m stucked at the following error currently:
set_control:1464: Cannot write control ‘2:0:0:HDA Maximum PCM Channels:0’ : Operation not permitted
I’ve spent quite a lot of time debugging the audio issue but haven’t really made any progress. It looks the like the stereo audio is played only from the left speaker and thus at half speed.
The pretty much same kernel works in Android so I think it should work in Debian as well, just with some user-space configuration or hack.
I’m not such a big hardware guy but should’t it be possible to solder a custom external switch? http://www.ifixit.com/Teardown/Ouya+Teardown/14224/1. Does anyone has more infos about the board (layout)
A custom external switch for what purpose..?
to get in recovery mode without boot aka a working kernel
http://forums.ouya.tv/discussion/1380/recovery-mode/p6
According to that thread you can solder a button to U33 and that will enable nvidia recovery mode (not the fastboot recovery mode). That would be otherwise awesome but it seems that you need to have proper encryption keys (or something) to be able to flash anything with it.
I haven’t seen any threads pointing out other places where a switch could be soldered in to.
Hi,
I tried to follow the README.md but failed at point: “Install Tegra 3 proprietary binaries…”.
The .deb file doesn’t seem to exist on my filesystem. I tried to run your “get-tegra-t30*.sh” scripts hoping to produce them, both downloaded files and finished ok. I also run make in the “tegra30-r16” directory, but that failed (cp: cannot stat `rootfs’: No such file or directory). Could you please explain how to get / create the “tegra30-r16_3-*_armhf.deb” file? Thanks.
Olin
The last sentence of my post has the pointer to the packages. You don’t need to create the packages yourself.
If you do want to create them youself you need to use debian tools on a running Ouya. So instead of running “make” in there, you need to run “dpkg-buildpackage”.
Completely missed the last sentence. Anyway, I’ve finished the installation and booted via fastboot. I can confirm it works for me perfectly! Many thanks!
I finally have audio working with alsa-utils disabled (not sure what it even does) and with simple alsa config.
Running video playback and a 3d benchmark doesn’t even increase the CPU frequency as everything is hardware accelerated.
The current tegra30-r16_3-3.1_armhf.deb has two flaws that are now fixed in the github but I haven’t yet created a new .deb:
1) /etc/ld.so.conf.d/tegra.conf should be renamed to 00_tegra.conf so that it’s read first (otherwise software OpenGL ES is used). Run ldconfig after renaming it.
2) /etc/asound.conf should look like this (iirc): https://github.com/kulve/tegra-debian/blob/master/tegra30-r16/overlay-rootfs/etc/asound.conf
Hi Tuomas.
In the Wifi configuration I see you access the internal flash from the Ouya through the /dev/mmcblk0p3 device.
Would it be possible to create a subdirectory into the /sdcard folder to implement the installation into the flash directly?
I assume we would need another kernel with the new location for the root “partition” (which would be a folder like /sdcard/root-linux).
Can we simulate the swap use with a swap dedicated file within the /sdcard/root-linux/swap.swp for example?
Best regards.
Carlos.
N.B.: The Ouya works quite well even using the USB2 Interface. :)
Are you asking if it would be possible to install to the Ouya’s internal flash instead of external USB flash drive? It should be possible but I intentionally want to avoid touching the interenals of Ouya until there’s a proper recovery mechanims. Also the Linux rootfs takes quite much space and Ouya doesn’t have that much flash.
Using a swap file instead of a swap partition might be an easier solution, yes.
Hi, Is there any new development? Which kernel do you use and which kernel config do you use to build it? I’d like to build few more modules… Thanks. Olin
Kernel:
https://github.com/kulve/ouya_1_1-kernel
Kernel config:
https://github.com/kulve/ouya_1_1-kernel/blob/linux-fixes/arch/arm/configs/ouya_linux_defconfig
About development. I’ve just realised that OMX is better supported in applications like XBMC and VLC than I thought and that there have been at least earlier something run on Tegra as well. So more work should be done to experiment with those.
EDIT: I also booted up Ubuntu Saucy. I used the same instructions as for Debian Wheezy with some minor changes. And the X.Org driver needs to be the ABI 14 one. I did get the Slim running on X.Org with something graphically odd when trying to login. And the login failed. Didn’t look into it any further as I was just remotely trying to compile XBMC.
Hi,here is my report:
I’ve recompiled the kernel and added some dvb-t card modules (thanks for the links to the sources). They work fine, modules are automatically loaded when the dongles are plugged to usb ports. I also tried to scan and record DVB-T stream and this works OK as well.
However, I was not able to play any audio or video via VLC or Media player. Player window stayed black, only resized according the video dimensions, and the cpu started to decode (I could see some increased cpu utilization). No audio though, I tried to switch to both analog and hdmi output without any luck (just a few cracking clicks when playback started). Next trial was ‘mplayer’ which started to play the audio for 3 second with black window (again) and after that it completely froze ouya. I doublechecked tegra.conf is renamed and the asound.conf is set as you suggested…
How do you check the video is hardware accelerated?
On Tegra3 only GStreamer is properly supported for hardware accelerated video/audio encode/decode/render. So unfortunately this rules out vlc and mplayer.
You should try out Totem as it has GStreamer backend. That works nicely for me. Although there is still one catch. The de-facto video sink (xvimagesink) doesn’t work and you need to explicitly set it to nvxvimagesink:
gconftool-2 -s /system/gstreamer/0.10/default/videosink nvxvimagesink –type=string
Or use gstreamer-properties which is a graphical application for setting the GStreamer audio/video sinks. With that, set the video output to “custom” and write nvxvimagesink to “pipeline” field.
Hi,
using ‘nvxvimagesink’ helped with the video in totem. However the audio had the symptoms you described earlier: sound only from one speaker and played half the speed. The more annoying is the video played twice as slow too because of the AV synchronization :).
I tried:
aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Tegra [HDA NVIDIA Tegra], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
…
aplay -D plughw:0,3 /usr/share/sounds/alsa/Front_Right.wav
-plays correctly from the right speaker
aplay -D plughw:0,3 /usr/share/sounds/alsa/Front_Left.wav
-plays correctly from the left speaker
aplay -D plughw:1,0 /usr/share/sounds/alsa/Front_Left.wav
-plays incorrectly DarthVader style!
accroding to this article:
https://wiki.archlinux.org/index.php/PulseAudio/Examples#Advanced_ALSA_Configuration
I modified /etc/pulse/default.pa and added these lines:
load-module module-alsa-sink device=hw:0,3
set-default-sink 0
then
killall pulseaudio
Aftert that totem audio and video started to play correctly! (I had to run totem as superuser though)
Just for information in gstreamer-properties the I have the audio output set to Autodetect.
Hi there.
I found a problem with the installation. Everything works pretty fine and I’m VERY happy with the Ouya running Debian but I found something weird.
During the installation when we are running in “chroot mode” we can access apt-get and dselect with no problems to install whatever we want… but after the installation when we run in “native mode” in the Ouya hardware I see the the dselect & apt-get cease to work and complains about some library loading problems (below you can see the error reported)
—-
apt-get: error while loading shared libraries: mbufIcSt11char_traitsIcEE: cannot open shared object file: no such file or directory.
—-
Any idea about this?. I repeat this happens afte the installation when running into the ouya not in the momment we are “bootstrapping” the debian installation.
Is anyone experiencing this?
Best regards.
juisjuis.
I haven’t tried dselect but I’ve used apt-get quite a lot on Ouya without any problems.
You can try “ldd /usr/bin/apt-get” see if it finds all the libs but I think the error would be different if something is really missing. And I guess everything is there if it works in the chroot environment.
Did you check “dmesg” that there are no file system errors?
Other than those I have no clue what might be happening. Are you running the Debian rootfs on USB stick? What size?
Hi Tuomas.
dmesg is clean.
The ldd command complains a lot the libstdc++.so.6… errors pasted below
—-
/usr/bin/apt-get: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `CXXABI_ARM_1.3.3′ not found (required by /usr/bin/apt-get)
/usr/bin/apt-get: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.9′ not found (required by /usr/bin/apt-get)
/usr/bin/apt-get: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.15′ not found (required by /usr/bin/apt-get)
/usr/bin/apt-get: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `CXXABI_1.3′ not found (required by /usr/bin/apt-get)
/usr/bin/apt-get: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.11′ not found (required by /usr/bin/apt-get)
/usr/bin/apt-get: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4′ not found (required by /usr/bin/apt-get)
/usr/bin/apt-get: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `CXXABI_ARM_1.3.3′ not found (required by /usr/lib/arm-linux-gnueabihf/libapt-pkg.so.4.12)
/usr/bin/apt-get: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.11′ not found (required by /usr/lib/arm-linux-gnueabihf/libapt-pkg.so.4.12)
/usr/bin/apt-get: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `CXXABI_1.3′ not found (required by /usr/lib/arm-linux-gnueabihf/libapt-pkg.so.4.12)
/usr/bin/apt-get: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.9′ not found (required by /usr/lib/arm-linux-gnueabihf/libapt-pkg.so.4.12)
/usr/bin/apt-get: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.15′ not found (required by /usr/lib/arm-linux-gnueabihf/libapt-pkg.so.4.12)
/usr/bin/apt-get: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4′ not found (required by /usr/lib/arm-linux-gnueabihf/libapt-pkg.so.4.12)
—-
The rootfs is mounted in a micro-sd card with usb adapter 16gb/class10.
I know it looks weird, but I followed the steps flawlessly 3 times and I see the error always after switching to the Ouya hard.
Best regards.
juisjuis
What’s your host PC distro in where you have the chroot?
Hi Tuomas.
It runs a Xubuntu/AMD64 installation. (I don’t remember the exact version)
Is that important?
Best regards.
juisjuis.
you may try to download the package (with the lib) manually from here:
http://packages.debian.org/wheezy/armhf/libstdc++6/download
and then unpack it to your SD cart as a root on your Xubuntu/AMD64.
I’m just trying to figure out why would apt-get work in chroot but not in the actual hardware.
Hi Toumas.
The solution proposed by “olin” works fine.
I just downloaded the pkg from debian manually from the http://packages.debian.org/wheezy/armhf/libstdc++6/download link.
Then dpkg -i libstdc++6_4.7.2-5_armhf.deb
and the apt-get & dselect commands work perfectly.
I couldn’t reply directly to olin’s comment directly.
Thank you.
juisjuis.
Nice to hear that you got it solved. I wonder what caused it and if you actually have something else broken as well. Let me know if you figure it out some day!
Btw, it seems that a multibooting could be possible after some tweaking:
http://forum.xda-developers.com/showthread.php?p=46328719#post46328719
Hi Tuomas.
We need to test that, I guess is a key point to have a 100% autonomous system.
The rest is working quite well and even the performance is VERY GOOD for a 99$ box.
I haven’t added the X support, I’m using it as a non-desktop box, because I don’t want the graphical interface to get to much resources.
I like this “tiny box” quite a lot.
Best regards.
juisjuis.
I also like the performance for a 99$.
Running 1080p desktop on that is quite much but it’s still usable at least for many use cases. And for watching h264 videos or for running something OpenGL ES based it’s even better.
Hi,
my xfce developed a problem with disrupted windows top panel (was fine at the beginning..). Manually changing theme in Settings->Window Manager fixes that, but unfortunately next time I login the situation repats. Any clue how to fix it for good ?
Looks like there’s a limit on the depth of replies so I can’t reply to olin’s comment about the pulseaudio.
I didn’t use pulseaudio. I usually have just problems with it on desktop, so I tend to always remove it as the first thing. But if it works with the config file you mentioned, I’ll add it to the package. Thanks!
I noticed that window decoration corruption as well. In my case it appeared after some mode changes with xrandr. And I have no clue about fixing it.
EDIT: And you shouldn’t need to run as root, as long as the normal user belongs to the “video” group.
adding user to the ‘video’ group helped inded! Thanks for that.
I’ve also found workaround for corruption of window decoration (http://ubuntuforums.org/archive/index.php/t-1384303.html) by adding ‘/usr/bix/xfwm4 –replace’ item to the Settings -> Session and Startup -> Application autostart. It’s not a proper solution as the corruption will re-appear in the next occasion (changing the video resolution for example), but at least the window decorations are OK after login.
Finally the Ouya Boot Menu was released (http://forum.xda-developers.com/showthread.php?t=2499673) by Hal9k+1 and I can report it works perfectly with your kernel!
Few things to mention:
1) The Ouy Boot Menu expects the kernel in ANDROID format (zImage + ramdisk). I used following tools to unpack / repack the kernel.bin: http://forum.xda-developers.com/showthread.php?t=1477845
That means you have to repack zImage (either from Tuomas or your own) with a ramdisk into kernelA1.img. I used a dummy ramdisk (empty directory with few dummy files) – just use the tools above. Note: when I used original ouya ramdisk (from the LNX partition – reffered as /sdcard/kernel.img) it didn’t work for me (kernel booted fine but didn’t find usb filesystem)
2) copy the kernelA1.img to ouya’s /sdcard/kernelA1.img
adb push kernelA1.img /sdcard/kernelA1.img
adb shell
sync
reboot
3) when the Boot menu appears (assuming you’ve used the boot102513.img – to start the menu directly when Ouya Boots) press Ouya button to switch to kernelA1
You can still boot the original Ouya kernel as it is saved in /sdcard/kernel.img
Many thanks guys (Tuomas and Hal9k+1) for that!
Did you test the configuration file? It should be possible to set the timeout value and the kernel to boot in the configuration file so that it will boot automatically to the selected kernel.
Anybody willing to create a “base image” and share it for public use in some cloud service so that it would be convenient for people to try it out? :)
Yes, I use the configuration file to boot to the linux directly – no need for user interaction or connection to a computer at all.
Yesterday I stared installation of Ubuntu saucy according your instructions on the other thread. So far I have a headless system working. I’ll see how big the whole image will be. If the size will be resonable I’ll try to upload it.
I did get quite easily the X.Org/Slim on the TV with Saucy but it did have some rendering issues (parts of screen not updating properly, iirc). Let me know how it goes. I’m sure Ubuntu will be more interesting to many than Debian (not to me, though :).
I found a (hacky) solution for Saucy’s rendering problem. It’s not the prtiest solution but it works for me. What I did:
– installed Raring on ouya (13.04) to test the are no video issues (they are not, it uses ABI 13)
– copied over X and Xorg from the Raring /usr/bin to Saucy
– copied ouver libpixman from Raring from Raring to Saucy (maybe it would work even without it)
– copied over whole /usr/lib/xorg directory from Raring to Saucy.
Why not using Raring then ? I found several cons:
– I could not properly setup network (probably my mistake)
– lightdm takes ages to load (Saucy’d lightdm loads much quicker) – maybe because of the lack of networking ?
– xubuntu-desktop seems to be too bloated (I amost run out of space on the 3.5 gig partition)
I’m pretty sure some linux/xfce guru would solve it easilly but I’m not that guy :)
Do you mean that the rendering problems are due to the ABI 14 X.Org driver?
I’m not sure whether it is exactly in the Xorg driver, but Nvidia’s release notes accompanied with the ABI14 drivers mentioned problems when doing regression tests. They hinted it may be caused by the pixman libray. I compiled the latest available pixman 0.31.2 and also the previous pixman 0.28.2 and it didn’t help when using ABI14 driver. When I replaced just the X, Xorg, tegra_drv.so and evdev_drv.so (X input system to be able to use keyboard and mouse, it used ABI19. Older Xorg needed ABI18) to ABI13 it still didn’t help, but worked without crash with the same rendering issues. Then I replaced the whole xorg directory and the issue was gone.
glES works (tested on glmark2-2012.12) on Saucy, but I had problem with gstreamer. It cannot find any plugins. I installed gstreamer-plugins package that installed bunch of other plugin packages, but that didn’t help. When the video file is opened totem shows a dialog that tries to locate (and possibly download) the codecs but it fails.
Here is the log:
(totem:2616): GLib-GIO-WARNING **: Missing callback called fullpath = ... file.avi
** Message: Missing plugin: gstreamer|1.0|totem|MPEG-1 Layer 3 (MP3) decoder|decoder-audio/mpeg, mpegversion=(int)1, mpegaudioversion=(int)1, layer=(int)3, parsed=(boolean)true (MPEG-1 Layer 3 (MP3) decoder)
** Message: Missing plugin: gstreamer|1.0|totem|MPEG-4 Video decoder|decoder-video/mpeg, mpegversion=(int)4, systemstream=(boolean)false (MPEG-4 Video decoder)
CRITICAL:Could not find any packages to operate on
** Message: No installation candidate for missing plugins found.
Hi again.
I’ve been disconnected for a while…
I tested the solution to boot directly kulve’s kernel and works very well.
This means quite a huge achivement. Now we have and Official Debian running into the Ouya.
Thanks to everyone that contributed to this.
Best regards.
juisjuis.
Hi Tuomas.
I guess I found a typo when reading the “Wi-Fi” part of the installation.
You stated in your manual this:
cp /mnt/etc/firmware/nvram_4330.txt /lib/firmware/
and I guess it should be
cp /mnt/etc/nvram_4330.txt /lib/firmware/
Best regards.
juisjuis.
Thanks, fixed.
I’ve made an Ubuntu 12.04 LTS disk image with Xfce4. It requires at least 4 Gig disk, basic instructions are inside the archive.
Link: https://app.box.com/s/ni5rttar4x40tss6kbxm