[dev] Mainline Linux on Ouya, help needed

Modding/Sideloading
#1

Good Evening,

I am preparing Ouya for submission to the Mainline Linux kernel.
The device runs linux extremely well, with a few kinks left to work out.
Unfortunately I only have an original Ouya with Samsung ram and the bcm4330 wifi chip.
I know there were at least two other variants of ram in the wild, variants Hynix A, and Hynix M.
Also there is another wifi chip out in the wild.

I specifically am looking for anyone with new hardware running the Hynix ram variants to test the dynamic frequency tables for those ram chips.

For now all I need is you to run <dmesg | grep DDR> (Edit: You will need to run dmesg as root) and post the output, it should be something like this:

[ 0.916492] DDR Strap Pin AD4: 0
[ 0.919808] DDR Strap Pin AD5: 0

If you are more adventurous and would like to step into running mainline linux on your Ouya, my repository wiki is here:
https://github.com/pgwipeout/linux/wiki

Thanks,
Peter Geis

3 Likes
#2

You definitely have a fan base following you. We’ll be checking into which OUYA’s we have and in the event we get newer ones, we’ll step up to offer testing.
We use Linux on our various devices and computers and even just picked up a Pinephone and are hoping to start developing for it.

#3

Hi @Peter_Geis, I’ve tried to follow your instructions on your site to build and run on my ouya, but I’m actually not seeing anything spin up.

I am not sure if i’m dying at the compile steps you listed, or the Ubuntu image, since I don’t have a serial out connected on my board at the moment.

Can you please provide the exact Ubuntu 20.04 image you used to boot?
Can you also please update your wiki with more in-depth build instructions? You skip a lot of steps (including the exact build commands used), which toolchain you’re using to cross-compile, etc.

EDIT:
For actual proper communication of my above, here’s what I’ve tried:
DefConfig Command: make ARCH=arm defconfig KBUILD_DEFCONFIG=ouya_defconfig
Build Command: make -j8 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- zImage modules dtbs
I’m using the apt-installable arm-linux-gnueabihf, not the Linaro variant or anything
I’m also using the Ubuntu image located here: https://mirror.csclub.uwaterloo.ca/ubuntu-ports-releases/20.04/release/ubuntu-20.04-preinstalled-server-armhf%2Braspi.img.xz

1 Like
#4

Good Afternoon,

In its current state it is not going to be easy to get running.

To save space, the tegra video drivers are not compiled in.
This is due to the arbitrary size constraint set by the original Ouya Bootmenu, which enforces the original boot partition’s size.
For this reason the serial console is pretty much mandatory.
I’m running a modified boot menu that permits much larger images.

For the Ubuntu image, I’m using debootstrap to install a base Ubuntu image onto a USB SSD formatted as ext4.
These images are very basic, and require some modification before they will even attach to the network on boot.
You will also need to install your modules into this image.

The raspberry pi image you are using is likely tweaked for RPi’s environment, since they do not follow the standard linux boot sequence.

The build commands are seriously easy:
make ARCH=arm ouya_defconfig
make CROSS_COMPILE=arm-linux-gnueabihf- ARCH=arm -j4 (the default build makes a zImage, modules, and dtbs)
To gather the modules for manual installation into the Ubuntu image, you can run:
make CROSS_COMPILE=arm-linux-gnueabihf- ARCH=arm -j4 modules_install INSTALL_MOD_PATH=…/modules_install

I plan on releasing a prebuilt modified boot image with my changes to permit larger kexec images.
I also plan on releasing a fastboot bootable image that you can use to play around without risking your existing installation.

As of now if you do not have experience working with embedded linux you will find this to be a rather deep pool.

1 Like
#5

Hi Peter,
Thanks for your response!

I’m not expecting it to work out of the box, I wanted to see if I could get it booted to where you had it, so that I could start poking around and seeing what I could get working. I am not by any means an expert in embedded systems, but I am trying to get more involved to become better versed in it. I’ve built some kernels and bootable images for simulated/emulated environments at my work, and this was a natural next step to dive a bit more in. I have an old Ouya kicking around and figured this would be a good use of the hardware - it’s using the Kingston memories though, sorry I wouldn’t be able to help with your request for more data at least.

My comments about documentation and being more explicit were because a lot of the steps you’ve listed in your Wiki are really high-level and general, and because there is implied information that may be obvious to you since you’re knee-deep in working on it means I and others may make an assumption you haven’t and we’d be spinning our wheels and wasting your time asking questions. I really appreciate the info you put in this thread - this explains a lot of the behaviour I’m seeing, and what got you to that stage, and what my next steps are going to be (getting my serial console connected).

I figured the rpi image would be tweaked and cause problems, but it was unfortunately the only armhf image they had readily available to download - I was hoping I’d get lucky. Your instructions just said you’d used a 20.04 Ubuntu image supporting arm7hf, so it was just an assumption I made that I wanted to rectify. I’ll use your method next to at least make sure I’m at parity to what you’re doing.

Oh, also, are you checking in your modifications for the boot image changes anywhere to allow larger kexec images? I’m curious to see what you did. I assume it’s not in the v5.8-ouya branch, as I hadn’t seen any updates for a bit of time on it.

I really do appreciate you taking your time to answer, in any case.

1 Like
#6

Good Afternoon,

I specifically kept the instructions high level because of the unstable nature of the project.
At this time the project is suited for those with experience, sort of like the early android hacking days.
Once the project is safer for general consumption, I’ll update the instructions to lower the bar of entry.
I’m sorry if this is inconvenient, but I don’t want someone bricking their Ouya accidentally.

The update for the boot menu is located here:

1 Like
#7

Hi Peter,
That is totally understandable, and thank you for responses so far, it’s much appreciated.

#8

An update on this.
I’ve got u-boot chainloading from fastboot.
It’s very glitchy, mmc doesn’t work the first shot half the time.
U-boot also doesn’t support hdmi output on tegra.
But over serial, it’s incredibly fast.

1 Like
#9

Fixed the MMC issue in u-boot, if anyone has a serial console working and they’d like to try it let me know.
It can be run from fastboot boot just like any other kernel.

1 Like
#10

I would be interested in trying. But I don’t have an OUYA I want to mess about with, at the moment. Soon perhaps.

#11

Hi Peter,
Happy new year!

I’ve gotten a USB UART dongle wired into my Ouya from when I first started poking at this using your repo, but ended up taking a break due to my other work obligations. If you’re still in need of someone to try out stuff on another system to compare against, do let me know!

#12

@Peter_Geis Have you seen this?


https://ouya.world/t/linux-5-11-on-ouya-c-2021/510

#13

I got my OUYA connected through ADB in Ubuntu and ran the <dmesg | grep DDR> command but I’m not sure I got the results you’re looking for.

snapshot1
snapshot11366×768 169 KB

#14

Yeah, that’s dmesg for your host, not the Ouya.
You have to run the command in adb shell.

#15

I see. Is that doable from Windows also?

I have 5 OUYA’s to do this to, so I hope to have something useful for you.

Also, is there a command to also see which wifi chip is being used? You said you might need to look at that too.

Also there is another wifi chip out in the wild.