yashsingh1/xdaforums huggingface dataset:
[JASJAR, XDA Exec, MDA Pro Software Upgrading] Daimaou:
Well this is not supprising me at all, since I had the same behavior on my Qetk 9090, and on my JasJar. I want believe (but I may be wrong) is that your CPU is not always at 100%, I used a Japanese soft a long time ago and the 10 sec after the boot of my PDA I had 160Mhz on 400 on a Xscale CPU, it seems to work like a Pentium M, anyway I am not a PRO, but I think that when you do a hard reset sometimes your CPU is a 100% of its capacity sometimes not.

But honestly I had this since a LONG LONG time on all my Xscale PDA, so do not worry
[JASJAR, XDA Exec, MDA Pro Software Upgrading] keke13:
Ok merci pour ton retour.

Je reste un peu sur cette Beta pour le moment qui n'est pas si mal et je verrais par la suite.

Envoyé de mon ONEPLUS A3003 en utilisant Tapatalk
[Nexus 7 (2013) Q&A] kris4o2:
Hi guys,

So I'm on a stock N7 all OTA updates including the new one and my notifications don't work.

No LED light, no sound, nothing in the notification bar.

When I get on facebook I see that I have like 3 messages in red, even gmail notifications don't show up.

My notifications were ok before - most of the time, only brief periods of inactivity but now it looks like they're gone for good.

So please guys do you know how to activate them again?

Thanks
[Nexus 7 (2013) Q&A] railed:
Do you have Sync on? Settings -> Accounts -> Sync
[Nexus 7 (2013) Q&A] kris4o2:
Thats for HTC btw, and yes I have sync always on :(
[Ouya General] Hal9k+1:
Hello everyone,

This thread previously was a discussion area for the Ouya Boot Menu feature during its early development.

It's now being transitioned to a support area. The new project description/download page is at:

http://xdaforums.com/showthread.php?t=2499673.

Thanks!
[Ouya General] View2Askew:
CWM Bootloop

Will this help with the problem I have?..

New update today it downloads automatically and then reboot to CWM and it fail verification...reboot system and it does all over again?...Any ideas Plz:confused:
[Ouya General] Hal9k+1:
Sorry, I'm not sure I understand. It sounds like the new stock firmware update is failing to go in, perhaps because of consistent download corruption. Whether you're actually being dropped in to the recovery partition is unclear. You might try the download again with the other networking type (Ethernet vs WiFi). You might also just disconnect from the network for the time being, and see if you remain in the firmware without interruption. From there you can consider setting up ADB to see if you can administer the Ouya from a PC.

My post is more for the developers at heart, just in case my investigation piqued anyone's interest. Ideally the post would go in the Development section, but I evidently need a few more posts here to unlock that area. :)

Best of luck!
[Ouya General] kulve:
Dual booting

Yes, please do enable dual/multi booting :)

Is there something I can do to help in that regard?
[Ouya General] Hal9k+1:
Thanks kulve, and thank you for the kernel patch set. I need to get familiar with the offerings there.

I don't see any blockages in my plan so far; I just need to start in and see what comes up. At least it's a better feeling than the dead-ends encountered with the U-Boot and regular KExec investigations.

Someone more enterprising could possibly port in the MultiROM project, but I'll stick with this. Will let you know if I get stuck.
[Ouya General] Hal9k+1:
My findings so far...

- I've finally decided that shutting off HDCP in the build does nothing to help avoid the funky pink/purple squeezed screen that sometimes appears when CWM comes up. With my Asus monitor, I see the issue when the monitor was in sleep mode. Likewise, if I can switch the monitor to HDMI input at the same time as starting Recovery, then it's fine. It may be possible to hack in a fix by somehow starting and closing an HDMI session shortly before CWM itself starts. (I don't want to fight this too hard but would be nice to resolve.)

- I see how to pull the kernel and ramdisk out of an Android image (on the Ouya itself), so that they could be passed to KExec-HardBoot. I've done it with a script as a test but it may end up in an executable.

- I tried out a USB thumb drive. It's detected but no block device is made available under /dev -- I've finally decided that support is likely in a kernel module, which does not exist on the Recovery image. I'm probably not going to sweat this due to the next item.

- I notice that the CWM application can read the Ouya power button as something comparable to a keyboard key press. Borrowing this capability may allow us to count the button presses in a limited time range, and thus boot an appropriate image. (Would be easier than dealing with the pairing of the controller, but at least still wouldn't require a keyboard.) With this line of thought, I'm thinking the main image could sit in /system while any alternates could be in /sdcard or /data.

So in general, studying the code of the CWM application appears to be the next direction. Thanks - feel free to send any ideas.
[Ouya General] kulve:
What does the rendering in CWM? Is it Android or something lower level? I think my kernel has better HDMI support but for that the software needs to use that explicitly instead of the default one as there is not internal LCD panel (/dev/graphics/fb0 vs. fb1).
[Ouya General] Hal9k+1:
It does look to be low-level, as CWM directly opens /dev/graphics/fb0 and uses ioctl() on it. I've decided to try my own compile of CWM as it does look to be a nice base for the booting effort. Will definitely look to your patches for the improved HDMI when I'm all ready -- thanks!
[Ouya General] kulve:
I noticed your comments related to this on the "Ouya CWM Recovery" thread but I'm not allowed to post there, so I'll post here.

Or actually repost as I'm mostly repeating myself. I had all kinds of issues in getting output using /dev/graphics/fb0 in Linux with the stock Ouya kernel but after some fixes the fb1 seems to work quite reliable. I get the output even if I don't have HDMI plugged in during the boot and it chooses the right resolution both for my TV (1080p) and for my monitor (1680x1050).
[Ouya General] Hal9k+1:
To all: I have updated the attachment that's present on the first post. I've synced to the latest Ouya kernel and pulled in the next HDMI patch set from Kulve. My HDMI issue now appears to be fully resolved.

Kulve: Thanks so much for refocusing me! I should have grabbed the patch from day 1, but that summary description had me a bit spooked. Note that I kept the HDMI/PRIMARY symbol enabled, so there's still only the fb0 device on this kernel.

With this handled and due to my thinking in general, I'm going to back away from trying to compile CWM itself -- I don't want to invest in CM10.1's environment at this time. Instead I will borrow CWM's UI and input technology to build an independent front-end with this Ubuntu/glibc environment I have working. My idea is to release another Recovery image when that's ready so we'll have a chance to practice/debug before moving to the Boot image.
[Ouya General] kulve:
Hit the Thanks button ;)

Anyway, do you have your kernel source code somewhere? Being able to use multiple resolutions on HDMI while keeping it as primary might be something that many Ouya Android gamers want as they might be able to play at 720p then.
[Ouya General] zondajag:
ooo nice, ill try it out and see what happens
[Ouya General] Hal9k+1:
Done! :laugh:

My modified files were tarred up and placed in the ZIP; let me know of any possible issue. I'm not planning on a GIT account, but anyone may feel free to pull anything back to their project. Also I understand that sticking with HDMI/PRIMARY may reduce some of the capability/flexibility you're seeing, but I wanted to stay honored to the Android/CM layout expectation if possible.
[Ouya General] zondajag:
Any chance of getting some concise installation instructions?
[Ouya General] Hal9k+1:
Here's a quick executive summary until I can update the 1st post.

I'm reminded there's another XDA project (Ouya Safe Recovery) with a very similar goal as this, and works by reversing the Boot and Recovery concepts. However it's completely incompatible with us, and those users should not be doing any flashing -- at least not until we have a Boot image ready.

First step is to get rcvy092613.img to the Ouya in its /tmp directory. This may be done with an "adb push rcvy092613.img /tmp" command, or can by done through Secure Copy if an appropriate SSH server is set up.

Next step is to access the Ouya shell, either running from the main ROM or from a Recovery ROM. Be sure to become root (ensure "#" in the prompt) as needed.

Run the following to back up the old image:

cd /dev/block/platform/sdhci-tegra.3/by-name/

dd if=SOS of=/sdcard/old_rcvy.img

Make sure the new image is correct - should see "2a882d1ba8c2d543503cacb49ab0d397":

md5sum /tmp/rcvy092613.img

On to flashing Recovery:

dd if=/tmp/rcvy092613.img of=SOS

Now wait at least a full minute in case there is any internal flushing still taking place. And to finish up:

sync

reboot recovery
[Ouya General] Hal9k+1:
Aye....never enough time to tinker it seems, especially with getting over this flu.

At this point I have my own compiled code splitting the boot image file, as well as counting the power button clicks.

I want to see if I can make a welcome/instruction screen, probably by getting CWM's minui down to its core essence. From there it will hopefully just be normal integration work to achieve a new Recovery for testing.
[Ouya General] Hal9k+1:
Everyone, a new boot menu is ready for testing. Please read through the first post to see if you'd like to try it out. Apologies once again for the delay in getting this ready.
[Ouya General] kulve:
Did I read correctly that the image support multibooting?
[Ouya General] Hal9k+1:
Hi again Kulve. It supports three Android boot images - the main + two alternates: kernel.img, kernelA1.img, & kernelA2.img. It prefers to see the selected image in /sdcard, but will shift to /system as needed.

So, it is multi-booting, but you should keep in mind that there is still only the single /system partition. So installing two normal ROMs together probably won't work out, due to that common storage area. However, one of the ROMs could be based out of /system, while any others could use some form of external/networked storage. Note that the Android image format contains both the kernel and the initial ramdisk, so I feel that a multi-boot arrangement could be done.
[Ouya General] kulve:
My kernel is hard coded to mount the Debian (or whatever) rootfs from /dev/sdaX so Ouya's internal partitioning doesn't matter. It would be really cool to be able to put kernelA1.im to /sdcard, an USB flash drive to the USB port and boot to Debian without tinkering with adb/fastboot/etc. on a PC.

I'm not currently using any initrd-images but adding something simple should be straightforward.
[Ouya General] Hal9k+1:
If you have an Android boot image of Debian that's working with Fastboot, then I feel it should work here as well. Otherwise if running mkbootimg for the first time, then you may be able to pass "/dev/null" as your ramdisk parameter and something like "root=/dev/sda1" for your command-line parameter.

I do hope your testing works as it would be fun to see dual-boot for real!
[Ouya General] juisjuis:
Hi all.

I tried to use the kernel selector to boot the Original Ouya android kernel.img and a Debian.img built ad-hoc (the one based on kulve's kernel).

Results:

1.-I couldn't launch the debian kernel image, but perhaps I used the mkbootimg in a non-proper way trying to build the Debian kernel img. I need to check that out

2.-I couldn't even launch the Ouya boot.img following the instructions described in the initial post in this thread. Do I need to use an specific Ouya android SO Version? When I try to launch the bootup process with the Original Ouya kernel I have the screen starts like "flashing" like if it would be making continuous attempts to launch the kernel image with no result. Then I can power-off & on the Ouya and leave it initiate the normal bootup process. I can reenter later on into the kernel selection process but it never boots up the image from the /sdcard folder I select.

I don know if I'm doing something wrong here, but I followed the instructions in the first post step by step with not too much result.

Best regards.

juisjuis.
[Ouya General] Hal9k+1:
Hi juisjuis,

Sorry about your bad luck so far. I hope we can sort it out.

1) I haven't tried Debian yet, though I understand it could be the "killer app" for this type of project. I do plan on trying it. It's possible the KExec technology has some kind of "guest" kernel restriction that I don't appreciate at this time. As a test, you could try a USB/wired keyboard, and see if it blinks at you during the boot process. That should show the kernel itself has come up.

2) Just for clarification, this is the part where you copied LNX to /sdcard/kernel.img? Could you let me know the ROM/version on your Ouya? I can try a basic test of it, hopefully without changing my /system content at this point. It might be HDMI related -- requiring a power cycle of your display device; I've seen this when testing the Ouya recovery and official CWM images via the boot menu.

My Ouya ROM looks to come up consistently, and can do Ethernet/WiFi/streaming, so I'll plan to create the Boot image and flash it. With that said, I'm still on this older stock 393 version, so hoping there's no uncovered gotchas. Just as with your finding, the boot-up takes longer and has some screen flashes along the way.

Thanks for testing! :cyclops:
[Ouya General] kulve:
For Nexus7 (Grouper) both the "host" and the "guest" kernels had to be patched but it seems that with Tasssadar's newer patches it's not needed anymore:

http://xdaforums.com/showthread.php?t=2472316
[Ouya General] Hal9k+1:
Yup, and I know I have his latter work. I was worried the Debian kernel had a different load address or other setting that was preventing the kick-off. However, I think we're fine. I grabbed that kernel myself, verified it was raw ELF format (which my loader doesn't support), so created an Android image with a null ramdisk. I tried it without setting up any kind of external storage: there was no sign of activity - not even the keyboard blink. However, the Alt-SysRq-X combo is working. I either get the keyboard to blink, or the Ouya enters Fastboot mode. I'm pretty confident it was the Debian kernel because the combo supposedly takes you to the Recovery partition on the newer (my) Ouya kernels. I decided I should also try the boot images for CM10 and StockPlus, just to see if I see anything like juisjuis's issue.

As part of testing of some application cleanup work, I found that I never get an image to appear (either my app or CWM) when the monitor was in sleep mode at the start. Argh...I thought that was working. I don't know if that can be resolved, but I do recall that I enabled that HDMI_PRIMARY symbol in the kernel compile, and I should try without it (allowing the 2nd Framebuffer device) in case it really is buggy. Hopefully this final testing won't take too long so that I can prepare the Boot version.
[Ouya General] Hal9k+1:
Testing is looking good so far. I verified the HDMI_PRIMARY conditional compile is a little buggy -- it is at least partially confusing the two framebuffer memory regions (the unimplemented primary/touchscreen display and the HDMI display). It may have no real-world impact, but why risk it? So I shut that off and instead added my own (brutally ugly) hack to the kernel that disqualifies the 1st (unimplemented) display, so that we get back to the single application device (fb0). Looks okay so far.

That by itself doesn't handle the lack of HDMI picture when coming up with the monitor in sleep mode. I'm not sure how that would be addressed in the kernel, but I found that a small pause and retry of a framebuffer "put" action is a fine workaround for my bootmenu application.

I successfully booted the CM10 and StockPlus kernel/ramdisk images. There was no video/image, and I really didn't expect any due to my incompatible /system content. But ADB services came up for both and I was able to verify the correct running kernels.
[Ouya General] kulve:
Please do tell if you test my kernel as well. It should enable the kernel prints on HDMI before even trying to mount anything so it might be convenient for testing.

Thanks!
[Ouya General] Hal9k+1:
Hmm..interesting. I did yours (zImage-3.1.10-tk3+) that other day, but never saw anything until I did that Alt-SysRq-X combo. It probably makes sense to return to that now, as there's still a little risk of not getting a full hardware (e.g., HDMI) reset with this booting technology.

I'll see if I can set up the external storage to get it farther as well. Just in case I need it, could you let me know what those hard-coded (mounting / launching) commands are, and how they're implemented? That is I understand your environment does not use a ramdisk nor is there a special command-line entry outside what the bootloader passes.

Thanks much!
[Ouya General] kulve:
I'm not exactly sure what you mean. Usually bootloader passes kernel arguments to the kernel but since I didn't get them working properly, I've hardcoded them in the kernel config and ignore everything the bootloader is passing. Basically I just copied the original arguments and appended the rootfs argument. So that's all in the kernel config file.

And I'm not using the ramdisk as usually I don't have reason for it (not on my PC and not on embedded) and I like to work with a single file instead of two. But if there are any benefits from using ramdisk, I certainly can use it. So e.g. if your multiboot environment assumes it, it's no problem for me to (learn how to create one and) provide it.
[Ouya General] Hal9k+1:
Ah yes...I had forgotten about that "rootfs" parameter, and didn't know command-line options could be embedded via the kernel compile itself...cool. I'm pleased to say your kernel is doing just fine -- I'm embarrassed to say that I didn't wait long enough last time before I switched the monitor input back to the computer. (The KExec booting requires a longer wait, but isn't bad.) Anyway, the kernel lines went by and stopped at the waiting for /dev/sda2 point...sweet stuff!

And along those same lines, I now see that the CM10 and StockPlus images are getting to the welcome (shimmering "U" symbol) screen. The latter actually went further, asking which launcher to start: Ouya or Baxy.

My monitor sleep mode / HDMI issue is now resolved in my kernel, thus I no longer need the workaround in the application.

So at this point, I have nothing left to do except for getting this stuff packaged and released. Have a great weekend!
[Ouya General] kulve:
What kind of ramdisk you used?

And was it so that with your system it will automatically boot the alternate kernel if found? For my project I need it to boot automatically to my system without any user interaction.

When you get your stuff packaged I need to update my instructions to be compatible. And maybe find a way to distribute a minimal Debian image for easy testing.
[Ouya General] Hal9k+1:
Hi, Kulve.

I passed /dev/null to mkbootimg's --ramdisk parameter to signify an empty ramdisk. If the kernel didn't have the rootFS location directly embedded, then I could possibly have specified it with "--cmdline root=/dev/sda2".

My recovery image (the only one that exists so far) will enter CWM automatically after 10 seconds of inactivity. When the boot image is prepared, the default image will be associated with the main kernel (kernel.img), and either alternate (kernelA1.img / kernelA2.img) (or Recovery) could be chosen by the user during the wait. I decided not to probe any attached USB storage for the image -- let me know if any issue with my plan.
[Ouya General] kulve:
Would it make sense to automatically boot to one of the alternate (A1/A2) kernels, if found? No need to probe external storages, just boot the alternate kernel after a shortish timeout (if found and user didn't use the menu to select something).
[Ouya General] Hal9k+1:
It sounds like your Ouya may end up at a remote location, thus all administration would be over the network. The current implementation has something similar. Once the image is chosen, which would always be kernel.img in your case, it would attempt to load from /sdcard. If that failed then it tries /system. So, you could have a production kernel in /system and a temporary/test image in /sdcard that would eclipse the /system one.

But I'm completely open to a different direction to help out. Let me know your thought, and I'll hold off on finalizing things here. Thx!
[Ouya General] kulve:
I would like to keep the primary kernel for Android, mostly in the hope of not bricking it too easily.

Would it get too complicated if there would be an optional(?) configuration file that could state the kernel to boot by default and the timeout. Timeout should not ever less than one second.
[Ouya General] kulve:
Remote in some sense, yes :)
[Ouya General] Hal9k+1:
Ahh...I was right...in a way. ;) Pretty nice! I see the LifeCam, and is that a mutilated Ouya in there as well? LOL.

Sounds good on the configuration file, so I'll work that in. Reminds me that I need to implement some form of watchdog timer, esp. since the filesystem mounts will now need to take place early on.
[Ouya General] Hal9k+1:
Well, I decided to try CWM (with keyboard) the other day, and come to find double-buffering on the framebuffer is utterly broken. It's making menu navigation difficult because you only see every other refresh. Very annoying, and yet it's working (though perhaps not double-buffered) on the official CWM image. I may pull in a bit of code from the latest Google sources, or I may have to somehow get the kernel to tell (lie to) CWM that there is insufficient room for double-buffering.

The application change for Kulve should go fine once I'm past this latest video issue.
[Ouya General] palito1980:
I want to flash recovery to my ouya and then put clean Android but I don't know how. Do I need to connect ouya to tv and cop and then flash or what?
[Ouya General] Hal9k+1:
I've resolved the issue where an image boot could take up to a minute to get started. It occurred on images where the guest kernel was not KExec-HardBoot-patched. The other things are now handled as well, so I've made release images and moved the project to the Development forum. This forum can continue in a support role.

Palito1980, I hope the new description over there can help. You'll probably want to learn ADB mode (micro-USB cable to computer) as a prerequisite for something like this.

Thank you everyone for your interest/support.
[Ouya General] jobzombi:
Can't boot

Keeps booting into the recovery. I pushed the stock boot.img file to /system/boot.img and still nothing. I also pushed an altboot.img to sd and that's also doing nothing. I had originally forgotten to relocate my bootimage before installing the boot menu. Now it doesn't seem to want to loop out of going to recovery.

=(

Anybody got a copy of the stock boot image from lnx? I was on the latest firmware. From my understanding, since I did not relocate it before I flashed it, it's pretty much gone at this point. Not sure if using someone else's will work, but I'm sure it should. Thank you!
[Ouya General] jobzombi:
A-Okay

Never mind got it working again.
[Ouya General] Ticiano:
The only thing that keeps me from trying CM11 is that I just don't know how to get completely back to stock. I'm not a newbie flashing custom stuff in Android devices, but this one is risky and I don't know if I can just "fastboot update stockrom" and get all things back to stock.

I really don't like this device and I think this CM11 solution is the only way to go, but I'm still apprehensive.
[Ouya General] TwitchyEye:
The stock packages contain both ROM and recovery so flashing one will get you back to stock. I think.
[Ouya General] UntoTheCruel:
I see that you mentioned disabling HDCP here, and upon installing your ROM, I am still unable to use direct capture on my Ouya. Is there a further option that I have to enable to disable it?