Database Develop

[Q] How to remove / replace the boot logo?

I have already successfully removed the boot and shutdown animations (incl. sound) via "adb shell" commands:
Code:
su
mount -o remount,rw /dev/mtdblock3 /system
mv /system/media/bootani.qmg /system/media/_bootani.qmg
mv /system/media/samsungani.qmg /system/media/_samsungani.qmg
mv /system/media/video/shutdown/shutdown.qmg /system/media/video/shutdown/_shutdown.qmg
mv /system/media/audio/ui/PowerOff.wav /system/media/audio/ui/_PowerOff.wav
mv /system/etc/PowerOn.snd /system/etc/_PowerOn.snd
mv /system/etc/PowerOn.wav /system/etc/_PowerOn.wav
mount -o remount,ro /dev/mtdblock3 /system
exit
or just download the attached shell script and execute it as su:
adb push nobootani.sh /data/local/nobootani.sh
adb shell
Code:
su
cd /data/local
chmod 777 nobootani.sh
./nobootani.sh
exit
Btw the tablet now boots much faster.
But the boot splash screen from Samsung is still there.
EDIT:
I found out that the boot logo is actually a JPEG image located in the Secondary Bootloader (sbl.bin) on partitions bml4 and bml5 (both are identical on my Tab).
The partion layout seems to be the same as for the Galaxy S series:
http://forum.xda-developers.com/wiki/index.php?title=Samsung_Galaxy_S#Modifications
(here you can also find the secret codes to check firmware etc.)
This command gives the partition info:
cat /proc/LinuStoreIII/bmlinfo
To dump any partition (e.g. SBL) to SD card:
dd if=/dev/block/bml4 of=/sdcard/bml4_dump bs=1
I attached the extracted boot logo.

Thanks xdadevel,
Followed your instructions above and it worked like a charm - my Tab boots up MUCH faster now.
I think to remove the Samsung boot logo you would have to edit something like init.rc in the bootimg, repackage it, and then copy it across.

Im trying to do this and get
Can not mount permission denied.
Failed for bootani.qmg, Read-only system file.
Any ideas?

xdadevel said:
I have already successfully removed the boot and shutdown animations (incl. sound) via "adb shell" commands:
Code:
su
mount -o remount,rw /dev/mtdblock3 /system
cd /system/media
rm bootani.qmg
rm samsungani.qmg
cd /system/media/video/shutdown
rm shutdown.qmg
cd /system/media/audio/ui
rm PowerOff.wav
cd /system/etc
rm PowerOn.snd
rm PowerOn.wav
mount -o remount,ro /dev/mtdblock3 /system
exit
Btw the tablet now boots much faster.
But the boot splash screen from Samsung is still there.
I've been reading about the methods for other Samsung devices, such as:
flashing a PDA tar with Odin
fastboot flash splash1
packing the logo png as an update.zip
None of these worked.
Instead I bricked my tablet and flashed "P1_20100909.pit" and "GT-P1000_P1000XXJK1.rar" (from samfirmware.com) to make it work again.
Click to expand...
Click to collapse
Very easy, thanks for the idea! I copied the files to my external SDcard just in case though... Maybe it would be nice for you to remind people of that. Cheers!

mklass said:
Im trying to do this and get
Can not mount permission denied.
Failed for bootani.qmg, Read-only system file.
Any ideas?
Click to expand...
Click to collapse
Have you rooted your phone?

smithdc said:
Have you rooted your phone?
Click to expand...
Click to collapse
Yes it is
Cheers

I hope this work on the US TMobile verison?
Sent from my Samsung Galaxy Tab

It does work on the U.S. TMobile tab, I tried it. to me it boots faster, but seems to shut down slower.

Thanks! I follow your instruction but instead of deleting, I just rename them with .old extension (maybe one day will need them.. who knows.. )
Now it boot much faster!!

Hi,
is there any way to replace the boot logo?

deafjam said:
It does work on the U.S. TMobile tab, I tried it. to me it boots faster, but seems to shut down slower.
Click to expand...
Click to collapse
Thanks in might give it a shot.
Sent from my Samsung Galaxy Tab

So again is there a way to replace the boot logo?
Sent from my GT-P1000 using XDA App

saintxseiya said:
So again is there a way to replace the boot logo?
Click to expand...
Click to collapse
As I pointed out in the first post the boot logo is located in the secondary bootloader partition which an ARM binary. The logo is not accessible via the file system. You would have to dump this binary, modify it and flash it again (e.g. with Odin).
The risk is that if something goes wrong (corrupted binary, signature check failed etc.) your device will not boot anymore. Not even into the flashing mode because it is also part of the secondary bootloader.
Such perma brick can maybe reverted with professional tools like JTAG if you are willing to disassemble your device.
http://www.ifixit.com/Teardown/Samsung-Galaxy-Tab-Teardown/4103/1
Noone so far seemed to replace the boot logo successfully.
One way could be to overwrite the original jpeg (see first post) with a black jpeg of exactly the same size (=20701 bytes). If there's no signature check and the jpeg format is valid this should work.

xdadevel said:
As I pointed out in the first post the boot logo is located in the secondary bootloader partition which an ARM binary. The logo is not accessible via the file system. You would have to dump this binary, modify it and flash it again (e.g. with Odin).
The risk is that if something goes wrong (corrupted binary, signature check failed etc.) your device will not boot anymore. Not even into the flashing mode because it is also part of the secondary bootloader.
Such perma brick can maybe reverted with professional tools like JTAG if you are willing to disassemble your device.
http://www.ifixit.com/Teardown/Samsung-Galaxy-Tab-Teardown/4103/1
Noone so far seemed to replace the boot logo successfully.
One way could be to overwrite the original jpeg (see first post) with a black jpeg of exactly the same size (=20701 bytes). If there's no signature check and the jpeg format is valid this should work.
Click to expand...
Click to collapse
Thanks for the answer!
I searched the net also about these mysterious qmg Files, i do not understand why is Samsung using that kind of files, it just makes us unhappy not to customize the tabs

thanks worked very well, however, I have the t-mobile tab and the t-mobile splash screen stills shows up on boot is there any way to get rid of that one or is it similar to the samsung one that your having trouble removing?

Just flash an unbranded firmware, they will be gone then
Sent from my GT-P1000 using XDA App

xdadevel said:
Noone so far seemed to replace the boot logo successfully.
One way could be to overwrite the original jpeg (see first post) with a black jpeg of exactly the same size (=20701 bytes). If there's no signature check and the jpeg format is valid this should work.
Click to expand...
Click to collapse
Actually it works to overwrite the boot logo in sbl.bin with a custom jpeg file. The size must be less or equal 20701 bytes. I filled the remaining bytes of the original jpeg data with 0x00 but be careful NOT to overwrite the bytecode after the jpeg!!
When booting the device I can see the custom logo for 2-3 seconds.
After that, however, the Samsung boot logo shows up again!
Must be located in another place as well.

This sounds great! Could you make a quick tut how to do that exactly please?
Is there a virtual testlab for the tab or an emulator?
Sent from my GT-P1000 using XDA App

saintxseiya said:
This sounds great! Could you make a quick tut how to do that exactly please?
Is there a virtual testlab for the tab or an emulator?
Sent from my GT-P1000 using XDA App
Click to expand...
Click to collapse
No, unfortunately not. Just flash the european firmware

kg4mxz said:
No, unfortunately not. Just flash the european firmware
Click to expand...
Click to collapse
I am already on jk5 i want to customize my tab.
Sent from my GT-P1000 using XDA App

[Q] HELP! Maybe brick?

I was trying to fix my NC and install the 1.0.1 firmware. So I tried to format everything back to factory setting so I went into clockwork mod recovery and thought formatting the system partitions would restore me back to factory settings. Well I formatted "boot" and now it will not boot.
tl;dr I formatted boot, is it bricked?
help?

wolffboy212 said:
I was trying to fix my NC and install the 1.0.1 firmware. So I tried to format everything back to factory setting so I went into clockwork mod recovery and thought formatting the system partitions would restore me back to factory settings. Well I formatted "boot" and now it will not boot.
tl;dr I formatted boot, is it bricked?
help?
Click to expand...
Click to collapse
http://nookdevs.com/Flash_back_to_clean_stock_ROM
Do "Method one: Eight interrupted Boots" and post what happens afterwards

As I understand it, it is not bricked. You need to go read both the Nookie Froyo thread and the Clockwork Thread in the Nook Color Development Subforum. There is a way to put Nookie Froyo on an sdcard. You then boot with that and there's a way to put stuff back on the NC.
Do you have a Clockwork backup?
If you can boot back into Clockwork, there are some copies of other folks nandroid backup available. You can then put that on your sdcard and restore it.
I don't have the exact answer for you, but I'm sure it can be fixed.

Geezer Squid said:
As I understand it, it is not bricked. You need to go read both the Nookie Froyo thread and the Clockwork Thread in the Nook Color Development Subforum. There is a way to put Nookie Froyo on an sdcard. You then boot with that and there's a way to put stuff back on the NC.
Do you have a Clockwork backup?
If you can boot back into Clockwork, there are some copies of other folks nandroid backup available. You can then put that on your sdcard and restore it.
I don't have the exact answer for you, but I'm sure it can be fixed.
Click to expand...
Click to collapse
Paul22000 said:
Do "Method one: Eight interrupted Boots" and post what happens afterwards
Click to expand...
Click to collapse
When I press the power button nothing happens. I.E. screen stays black. Would your guy's ideas work if you can boot at all?

wolffboy212 said:
When I press the power button nothing happens. I.E. screen stays black. Would your guy's ideas work if you can boot at all?
Click to expand...
Click to collapse
I had the same thing happen. I tried plugging it into my Macbook, but nothing happened. I plugged into my Windows PC, and it came back to life.

A nookie froyo SD card would work fine. Restore from there manually. Next time make a nandroid and do not delete things that you do not know...

Syco54645 said:
A nookie froyo SD card would work fine. Restore from there manually. Next time make a nandroid and do not delete things that you do not know...
Click to expand...
Click to collapse
i have a nandroid back up and i cant get into recovery mode.

Because you deleted boot. Use a nookie froyo SD card and put the contents of boot back manually.

wolffboy212 said:
i have a nandroid back up and i cant get into recovery mode.
Click to expand...
Click to collapse
Which button combo are you trying to use to boot into recovery mode? If you haven't already, make sure you're using the three-button method.
Sent from my Nooted friend...

I have gotten it to boot to froyo on my sd card.
Now I need help restoring the boot partition from there.
Thank you very much with the support so far

It is not three buttons. Only need home and power.

wolffboy212 said:
I have gotten it to boot to froyo on my sd card.
Now I need help restoring the boot partition from there.
Thank you very much with the support so far
Click to expand...
Click to collapse
I am not certain what to do exactly as I have never used nookie froyo. Generally you are going to want to do
modified /system/boot
mount -t vfat /dev/block/mmcblk0p1
then put the files back in there from in nookie froyo.
Someone else may have the exact way. Sorry I cannot be of more help but that will mount boot when in stock. Of course you will have to mount system as RW as well.

Syco54645 said:
I am not certain what to do exactly as I have never used nookie froyo. Generally you are going to want to do
modified /system/boot
mount -t vfat /dev/block/mmcblk0p1
then put the files back in there from in nookie froyo.
Someone else may have the exact way. Sorry I cannot be of more help but that will mount boot when in stock. Of course you will have to mount system as RW as well.
Click to expand...
Click to collapse
Bare with me I know very basic unix and linux commands but I do have the brain capacity to figure things out (not boot partitions).
I was on the command line and I couldn't get into the nook color stuff just the nookie froyo stuff on the sdcard.
suggestions?

Please read CW recovery thread. All answers are in there!
Really, please take time to browse through existing threads before posting questions which have already been answered several times.
Anyway, considering the number of people asking, here goes:
Note: You can do all this from the Nook, without the need of ADB, except for the fact that you will need gapps on nookie in order to install terminal and root explorer (although you could install those apps by directly installing APK's), see http://nookdevs.com/NookColor:_Nookie_Froyo_Tips, Third-party app support
Please read entire thread before attempting anything!
- Boot into nookie with market installed.
- Install terminal emulator.
- Install root explorer
- Create a new folder at root (/), for example "boottmp" => "/boottmp"
- Launch terminal emulator
- type: "su"
- type: "mount /dev/block/mmcblk0p1 /boottmp"
- type: "echo -n -e "\x08\x00\x00\x00" > /rom/devconf/BootCnt" (this will force reset on next boot, as if you did 8 failed boots)
- open browser
- Download boot.zip from here: http://forum.xda-developers.com/showpost.php?p=10470539&postcount=268
- copy zip content to "/boottmp", by replacing existing files
- shutdown
- remove sdcard
- power up, you should see installation process after splash screen. Wait for it to finish, and it will reboot.
- power off
- Next you need to reset to factory settings:
- Boot while using power button and N button. Should boot to menu allowing reset. Proceed with reset.
Boot and be happy.
OR,
If you're able to access ADB (available when booting CW recovery and mounting /system and /SDcard, format from android required on SD to work here), CREDIT GOES TO Duloz, try this:
adb push uRecRam.bak /sdcard/
adb shell
su
mount -o rw,remount -t ext2 /dev/block/mmcblk0p5 /system
mkdir /system/boot/
mount -t vfat /dev/block/mmcblk0p1 /system/boot
cat /sdcard/uRecRam.bak > /system/boot/uRecRam
umount /system/boot
rmdir /system/boot
Click to expand...
Click to collapse
Note: Don't worry about errors concerning unmount.
If you're not back in business, post your questions, being very clear about what worked and what didn't.
Thank you.
Sent from my HTC Desire using XDA App

Back from Clockwork Recovery to Virgin (Factory) Recovery ... works like a charm!
samuelhalff said:
Please read CW recovery thread.
- Boot into nookie with market installed.
- Install terminal emulator.
- Install root explorer
- Create a new folder at root (/), for example "boottmp" => "/boottmp"
- Launch terminal emulator
- type: "su"
- type: "mount /dev/block/mmcblk0p1 /boottmp"
- type: "echo -n -e "\x08\x00\x00\x00" > /rom/devconf/BootCnt" (this will force reset on next boot, as if you did 8 failed boots)
- open browser
- Download boot.zip from here: http://forum.xda-developers.com/showpost.php?p=10470539&postcount=268
- copy zip content to "/boottmp", by replacing existing files
- shutdown
- remove sdcard
- power up, you should see installation process after splash screen. Wait for it to finish, and it will reboot.
- power off
- Next you need to reset to factory settings:
- Boot while using power button and N button. Should boot to menu allowing reset. Proceed with reset.
Boot and be happy.
Click to expand...
Click to collapse
Works perfectly, thanks! I actually used adb instead of root explorer to do the copy and mount (etc.) commands, and did a manual 8-times power start interruption, but essentially the same. This made my poor "sound-failing" Nook a virgin again so I can swap it out at the store today. Crossing fingers that they will provide quick and easy exchange service (and let me test the sound on the replacement before I leave the store!)... Then, back to Autonooking (and even back to Clockwork Recovery...) again; now that I know how to go back and forth.
Owe you (or y'all) a beer!

[GUIDE] How to get root on the 10.1v

BEFORE YOU BEGIN
As always, mucking with your device at this level is risky. If you follow this process, you do so entirely at your own risk. I accept no responsibility for any detrimental effects resulting from following this process, or for any problems associated with the updated files. Only if you accept these risks should you use these instructions.
PREREQUISITES
Unlocked bootloader (see my guide to do this)
Working fastboot (also see my guide )
Patience
NOTES
I developed and followed this process on Ubuntu Natty, 64bit. I see no reason why it should not work on any other platform, since the only tool used is fastboot and the syntax for fastboot is the same on any platform. if you need to know how to get fastboot working, there are already many guides for that (see my how to unlock your bootloader thread, for example)
BUTTON CONFUSION
When in landscape mode, with the camera at the top, the power button is on the left 'vertical' side of the tab. On the top is the volume rocker. In this orientation:
- The LEFT side of the volume rocker is VOLUME DOWN
- The RIGHT side of the volume rocker is VOLUME UP
This might seem obvious, but to anyone who is used to phones, this is the opposite, since they were designed to be used in Portrait mode.
PREPARE
1) With your Tab in fastboot mode (step 1 of "GETTING ROOT" below), make sure you have a working fastboot implementation:
Code:
fastboot devices
If all is well, you should see your device serial number. If there is a problem, you won't get any response.
2) Downlad View attachment skitzandroid-10-1v-root_0.2.zip and View attachment skitzandroid-stock-recovery.zip
3) Create a folder on your desktop called "root"
Code:
mkdir ~/Desktop/root
for Ubuntu or
Code:
md %userprofile%\desktop\root
for Windows
This will be referred to as the working directory throughout the rest of this guide
4) Copy skitzandroid-10-1v-root.zip to your working directory (DO NOT UNZIP!)
5) Extract the skitzandroid-recovery.img file from skitzandroid-stock-recovery.zip to your working folder. Your working folder should now have 1 IMG file and one ZIP file.
6) This was an afterthought - Make sure fastboot is somewhere in your path (ie can be executed from anywhere). To test, 'cd' to any random folder and type 'fastboot' and make sure it runs.
7) Copy the skitzandroid-10-1v-root.zip file to the root of your sdcard. You can eithe drag/drop, or run:
Code:
adb push skitzandroid-10-1v-root.zip /sdcard/
from your working directory
...now the easy part
GETTING ROOT
1) Power off your Tab and power it back on, while holding the VOLUME DOWN button.
2) When the DOWNLOAD / FASTBOOT icons appear, press VOLUME DOWN again to select FASTBOOT icon (the one with the USB logo) and press VOLUME UP to confirm selection.
3) Confirm you are now in fastboot mode and do a:
Code:
fastboot devices
If all is well, you should see your device serial number.
4) Open a terminal / CMD prompt and CD to your working folder
Code:
cd ~/Desktop/root
for Ubuntu or
Code:
cd %userprofile%\desktop\root
for Windows
5) Run the following command:
Temp Root:
Code:
fastboot boot skitzandroid-recovery.img
..and wait. It might not look like anything is happening but it is.
Permanent Root:
Code:
fastboot flash recovery skitzandroid-recovery.img
6) You should now have a recovery menu. Use the volume rocker (up/down navigates menu options) to select "Install zip from SDCARD" (or something like that - if someone can post the exact menu item wording, I will update the guide). Press (tap!) the POWER button to confirm the menu selection
7) Navigate to the root of your internal storage (/sdcard), select the skitzandroid-10-1v-root.zip file and press (tap!) the POWER button to confirm selection.
8) Once complete, use the Volume rocker to select "REBOOT" from the menu and press (tap!!!) the POWER button to confirm selection.
9) You're done! Press the thanks button on this thread to continue
TESTING
1) Once your Tab boots up, check your apps menu to confirm the existence of SuperUser app.
2) With the Tab attached to your PC via USB cable, do the following:
Code:
adb shell
su
..and watch the screen on your Tab for a SuperUser prompt. If you see this, congratulations!
If you have never rooted a phone/tablet before, go get Titanium Backup Pro and ROM Manager from the market. As soon as the custom ROMs start flowing in, you'll be all set to go.
Edit: How about thanking smaskell who was very patient and persistent in dumping the image from his Google IO 10.1 - for the good of his fellow XDA members. Without his help, this would not be possible.

Note that the above process doesn't flash the recovery, just loads it.
If you want to flash the recovery permanently, all you need to do is follow the guide above and then, in step 5, use this command instead:
Code:
fastboot flash recovery skitzandroid-recovery.img
You will then have a permanent recovery which you can get to by doing:
Code:
adb shell
su
reboot recovery
at any time.
Note that doing just
adb reboot recovery
Click to expand...
Click to collapse
...for some bizarre reason does not boot to recovery. Open up a shell first, as shown above.
I will also give you credit in the guide for having "Balls of Steel" to steal a phrase from PaulObrien
EDIT:
...and the Balls of Steel award goes to *drumroll*
Egan
...for having the balls to flash the recovery. Thanks egan. If I was in a battle, I'd definitely want you in our squad

FAQ
Does it need unlocked bootloader? Yes, see my other guide for this.
Do I need to wipe, or will it wipe my device? No and No.
Can I return my device to factory default config? Yes. This process does not flash the partition unless you follow the process in post 2 which is optional.
Changelog
0.2 - Added busybox (can be flashed over the top of 0.1 without wipe)
0.1 - Initial Relase
Factory Voda Tab Images
Recovery
Boot
System

Awesome news! Thanks to everyone who worked on this - I can't wait!

Great, great job you guys! This thing needs root so it can grow

Thanks a lot bcmobile and smaskell! Ill give it a go around launch.
Sent from my LG-P990 using XDA Premium App

Thank you guys, it's working great on my 10.1v

I'm pretty sure I know the answer to this already - but is there anyway of getting temp root on these devices so I can backup all my apps and data (properly) before unlocking / flashing recovery / rooting??

This wont make any changes to the partitions. You could undo the whole process by just deleting a few files.
The process in my second post would actually flash the image, and would be permanent if you had no 'factory' recovery image to flash back.
The 'standard' process in post 1 is normally used for testing and doesn't overwrite the recovery partition

Thanks a lot. Works like a charm
Now to make a full "original" fastboot flashable restore fileset:
Boot: dd if=/dev/block/mmcblk0p5 of=/sdcard/boot.img
System: dd if=/dev/block/mmcblk0p4 of=/sdcard/system.img
Would this be enough to have a proper "original" image? (With the small addition of root offcourse)
(Did a dd of dd if=/dev/block/mmcblk0p1 of=/sdcard/efs.img too, just to have a backup
Will see if I can make a full nandroid back-up now
Before flashing any recovery images etc..

gjroeleveld said:
Thanks a lot. Works like a charm
Now to make a full "original" fastboot flashable restore fileset:
Boot: dd if=/dev/block/mmcblk0p5 of=/sdcard/boot.img
System: dd if=/dev/block/mmcblk0p4 of=/sdcard/system.img
Would this be enough to have a proper "original" image? (With the small addition of root offcourse)
(Did a dd of dd if=/dev/block/mmcblk0p1 of=/sdcard/efs.img too, just to have a backup
Will see if I can make a full nandroid back-up now
Before flashing any recovery images etc..
Click to expand...
Click to collapse
That's all the backup I have done so I hope so
Just uploading a new version of the update zip (v0.2) which includes busybox

bcmobile said:
This wont make any changes to the partitions. You could undo the whole process by just deleting a few files.
The process in my second post would actually flash the image, and would be permanent if you had no 'factory' recovery image to flash back.
The 'standard' process in post 1 is normally used for testing and doesn't overwrite the recovery partition
Click to expand...
Click to collapse
Sorry, I realise that applying the root won't wipe anything, but unlocking the bootloader comes with a nice factory reset if I'm not mistaken..

gjroeleveld said:
Now to make a full "original" fastboot flashable restore fileset:
Boot: dd if=/dev/block/mmcblk0p5 of=/sdcard/boot.img
System: dd if=/dev/block/mmcblk0p4 of=/sdcard/system.img
Click to expand...
Click to collapse
Sorry for the ignorance, but are these fastboot or a adb commands?

Good work!
You should mention that you can't unlock and flash the Root-Update in one step.
The recovery complains then that /data/media is missing
Regards
EDIT:
black beard said:
Sorry for the ignorance, but are these fastboot or a adb commands?
Click to expand...
Click to collapse
These are adb commands you need to do with su!

black beard said:
Sorry, I realise that applying the root won't wipe anything, but unlocking the bootloader comes with a nice factory reset if I'm not mistaken..
Click to expand...
Click to collapse
That is part of the recovery image, not the unlocked bootloader.
You can always put back a stock image using fastboot which is one of the really nice things about fastboot unlocking vs bootloader exploits. "fastboot oem unlock" can then be undone by "fastboot oem lock" and nobody would know the diff.

seraphimserapis said:
Good work!
You should mention that you can't unlock and flash the Root-Update in one step.
The recovery complains then that /data/media is missing
Click to expand...
Click to collapse
Thanks!
Yeah, oem unlock doesn't actually do anything until the next boot

Egan said:
Thanks a lot bcmobile and smaskell! Ill give it a go around lunch.
Sent from my LG-P990 using XDA Premium App
Click to expand...
Click to collapse
Works like a charm! Now lets backup the original recovery and then flash the stock recovery .

Egan said:
Works like a charm! Now lets backup the original recovery and then flash the stock recovery .
Click to expand...
Click to collapse
Are you going to flash it?
You will earn the official "Balls of steel" badge

Thanks,
Also remember to enable USB debugging after you have done the unlocked bootloader, took me 5 min to to realize why adb did not want to work, 5 scary min after the reboot.

I've tried to make a proper nandroid backup but haven't been able too.
Tried with romdump 0.72 but that crashes :-(
Most tutorials use Rom Manager, but that needs some work from @koush before we can use it.
I'll google on
Sent from my GT-I9000 using XDA Premium App

[WIP][ThinkTank] Alternate Boot Methods (Safely boot CM10 from usb)

This thread is for brainstorming and developing safe ways of booting our OUYAs to use custom ROMs.
I've developed an initial method that allows OUYA to boot CM 10 from a usb thumb drive that does not require you to mess with any of your internal storage at all! This allows you to keep your OUYA in pristine stock condition, while still enjoying CM 10 from an external thumb drive.
Unfortunately it does require you to setup the thumb drive in a particular way to allow it to be used and this may be difficult for some users without Linux experience. I hope some will find it useful and plan to develop easier methods in the future (probably involving a custom recovery image with the ability to setup the thumb drive for you)
I plan to post more details on how I achieved this so that others can use the knowledge and apply it to other roms or develop improved solutions, but I might work on some other things first. Mainly it involved unpacking/repacking the Android boot.img (google it and there are tutorials about how to do this, I also recommend checking out the "abootimg" program from the Ubuntu packages) and modifying a couple of the init/fstab files.
Note that the zip I am going to link to is not a flashable zip, extract it and follow the instructions in the README which I am including below. Also note the the Google apps are not included - so if you want them you will need to add them yourself. Just be aware things you add to the system partition will need correct permission set.
One of my other ideas I'm going to eventually try is swapping the boot/recovery partitions so that the device normally boots up into recovery and then will have an option to reboot into the recovery partition which would actually boot a full rom for regular use. This may still be dangerous on OUYA though, so is not recommended unless you know what you're doing. I have a Notion Ink Adam which I can boot into APX mode (a low-level nVidia recovery mode that can be used to restore the device in the case of bricking, unfortunately we do not have this level of acces on OUYA), so it will be much safer for me to experiment on it. I haven't really developed on it before though (in fact this OUYA bit is my first major Android development apart from doing/tweaking some CM builds from source myself for some of my devices), so it may take me some time to set stuff up to experiment with it.
Eventually I think we need some form of bootloader for the OUYA. I have read about some very interesting kexec hardboot patches that were developed for the original Nexus 7 that it would be very awesome if we could port to OUYA - that would allow us to boot the patched kernel and have it boot us into kernels/roms stored elsewhere.
Please post any feedback or ideas. Sorry the current method isn't that easy yet and I hope the instructions make sense - hopefully others can also help clarify.
If you'd like to donate to me, I'm certainly not going to turn you away, but keep the other devs in mind 'cause I haven't done that much yet! ( PayPal: [email protected] )
~Troop

ouya-sda123-boot by Trooper_Max
Safely boot your OUYA to CM 10 without messing with your internal storage! (fast thumb drive recommended!)
========
Credits:
========
khanning88 for the initial CM10 Experimental ROM - this is just a repackaging/reconfiguration of it.
mybook4, sonofskywalker3, rayman, professorpoptart for their CWM recovery
And of course the CyanogenMod/ClockworkMod team for the basis of everything!
=========
Contents:
=========
ouya-cm10-system.img:
ext4 system image dumped from CM 10 experimental OUYA rom
ouya-sda123-boot.img:
Android boot.img to boot CM 10 from thumb drive partitions (details below)
==============
Prerequisites:
==============
For this current method, you will need to be able to partition the thumb drive into three ext4 partitions. This probably means you need Linux - if you don't have a Linux system, I highly recommend checking out pendrivelinux.com for methods of booting Linux off of a thumb drive (I recommend Ubuntu 12.04 LTS or whatever version you are comfortable with).
I hope to develop more methods in the future that will be easier than this, but this is the initial method.
=============
Instructions:
=============
1. Partition the thumb drive with three ext4 partitions - note that they must be the first three partitions on the thumb drive, and I would likely just dedicate a thumb drive to this. I recommend using Disk Utility or gparted (usually both available from an Ubuntu thumb drive).
* The first partition will be the data partition and should be the largest
* Note that Android will create the virtual sd card at /data/media
* The second partition will be system (OUYA internal system is 512 M)
* The third partition will be cache (OUYA internal cache is 768 M)
* Feel free to adjust the size of the partitions, but I'd recommend sticking close to the stock sizes
* I've tested this on an 8 GB as well as a smaller 4 GB thumb drive, bigger should not be a problem
2. Note the device name of your thumb drive - It will likely be sdX where X is a letter corresonding to the order it was mounted in - I would expect it to be sdd if it happens to be the fourth drive connected to your machine. The system partition will then be sdX2.
3. Write the ouya-cm10-system.img to the second partition of the thumb drive. It is crucial that the files get copied into the partition with the correct permissions.
* The easiest way to ensure this is to use dd to do a byte for byte copy of the system image directly over the partition, but this is also very dangerous if you type it wrong, so be sure you have the write device name for your thumbdrive.
* I recommend looking in the Disk Utility or gparted, or running "mount", "df -h", and "cat /proc/partitions", to make sure you have an understanding of what drives are what device names before continuing
* Once you are certain of the device name, ie sdX2, where X is the letter for the thumb drive and 2 denotes the second partition which we are using as system, run "dd if=ouya-cm10-system.img of=/dev/sdX2 bs=4M" as administrator (on Ubuntu either by sticking the word "sudo" in front of the command or running "sudo su" first to switch to root)
* This command will not show any output until the end and may take a little while.
4. Clean/fix the filesystem and resize the filesystem to fill the partition.
* Run "esfsck -fp /dev/sdX2" as administrator
* Run "resize2fs /dev/sdX2" as administrator
5. Thumb drive is now ready (the data/cache partitions can be empty ext4, Android will fill them in). Connect it to the OUYA. Through a hub is fine - just be sure it is the only thumb drive connected at boot.
6. Boot the OUYA into fastboot mode. The only real way to do this right now is to first boot up the OUYA normally, then use "adb reboot bootloader" to reboot into the bootloader. You should be able to run "fastboot devices" then and see a device listed.
7. Boot ouya-sda123-boot.img using the command "fastboot boot ouya-sda123-boot.img". You should see it download to the OUYA and it should start booting.
8. Wait patiently. Remember that CM boots slow the first time and depending on the speed of your thumb drive may boot even slower. You can however type "adb devices" to see if it has started the adb daemon. If you don't see a boot animation after a while, you can try running "adb shell" and if you get a permission error, it probably means you didn't flash the system partition correctly, but hopefully all goes well. Note though that once it gets farther into the boot sequence it will turn off the adb daemon so you will lose adb access until it boots up and you can re-enable it.
9. Enjoy CM 10 on your OUYA without having messed with your internal storage! Just be sure not to let your OUYA fall asleep, as it may not be able to wake back up! I'm guessing this is because I was using a hub and so when it falls asleep, the thumb drive essentially gets disconnected and it cannot immediately find it again when it tries to resume. I'd recommend using a wakelock application or power toggle to keep the screen on all the time, etc.
========
For Help
========
Look for us on the XDA Developers Forum under the appropriate threads! Keep in mind that using this method to boot CM 10 may introduce new bugs that would not have occurred using CM 10 the regular way, so be sure to report problems in the appropriate place and mention what methods you used!
Click to expand...
Click to collapse
http://troopermax.com/releases/ouya-sda123-boot.zip
(be gentle - it's 145 MB, I use shared hosting, so feel free to mirror)
md5sum: 49c8e16e27b6deb9d1e8e86363b56f2f
Mirror: http://www.mediafire.com/download/hban76kzeys6ybd/ouya-sda123-boot.zip
~Troop

I'm including some rough developer details here for now about how I did it.
Many thanks once again to the OUYA CWM recovery, I found it insanely useful: http://forum.xda-developers.com/showthread.php?t=2295645
The main part was unpacking/modifying/repacking the boot.img (which contains the kernel/ramdisk/etc)
abootimg helped with this greatly:
http://manpages.ubuntu.com/manpages/precise/man1/abootimg.1.html
Then I followed instructions I found via google for unpacking/repacking the ramdisk:
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
The partitions the OUYA uses are mostly defined in fstab.cardhu:
# Android fstab file.
#<src> <mnt_point> <type> <mnt_flags> <fs_mgr_flags>
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK
# We remount because we first mount as rw in order to generate NVSI symlink. See init.rc for details.
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro,remount wait
/dev/block/platform/sdhci-tegra.3/by-name/CAC /cache ext4 noatime,nosuid,nodev,journal_async_commit,data=writeback,nodelalloc,errors=panic wait
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 noatime,nosuid,nodev,journal_async_commit,data=writeback,nodelalloc,errors=panic wait,encryptable=/dev/block/platform/sdhci-tegra.3/by-name/MDA
Click to expand...
Click to collapse
I found that I could use fastboot to boot into the CWM recovery and then use adb pull to dump images of the internal OUYA partitions, using the paths above, ex. "adb pull /dev/block/platform/sdhci-tegra.3/by-name/APP ouya-system.img" to dump the system partition. I did a regular clockwordmod backup first, but adb pull was useful here for pulling raw images.
So after backing up my OUYA stock system, I actually did flash the CM10 rom so that I could dump the partitions to my computer using adb. The main reason I did this was to ensure the system partition gets generated with the correct permissions. I didn't boot into CM10 though, though I was tempted. Instead I restored back to my backup to put my OUYA back in stock condition.
With the system image dumped into a file, I used resize2fs to shrink the file to the minimum size (resize2fs -fM ouya-system.img) This probably wasn't absolutely necessary since it would compress down in the zip, but this allows it to be written to smaller partition sizes.
http://manpages.ubuntu.com/manpages/precise/en/man8/resize2fs.8.html
Here is what I modified the fstab.cardhu to:
# Android fstab file.
#<src> <mnt_point> <type> <mnt_flags> <fs_mgr_flags>
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK
# We remount because we first mount as rw in order to generate NVSI symlink. See init.rc for details.
/dev/block/sda2 /system ext4 rw wait
/dev/block/sda3 /cache ext4 noatime,nosuid,nodev,journal_async_commit,data=writeback,nodelalloc,errors=panic wait
/dev/block/sda1 /data ext4 noatime,nosuid,nodev,journal_async_commit,data=writeback,nodelalloc,errors=panic wait
Click to expand...
Click to collapse
Pretty straightforward, except that I removed the encryptable part on /data (not sure how that bits work and if I might have broken it) and made system read/write.
Also note, that I removed the initial read/write mounting of system in init.cardhu.rc since I was having trouble with it mounting from there (I'm guessing because my usb hub/thumb drive weren't yet available when that tried)
Here's the relevant part of init.cardhu.rc:
Before:
on fs
setprop ro.crypto.tmpfs_options size=128m,mode=0771,uid=1000,gid=1000
setprop ro.crypto.umount_sd false
# PLEASE DO NOT REMOVE NVSI SYMLINK! IF CHANGES ARE NEEDED PLEASE ENSURE THAT NVSI SYMLINK IS ALWAYS CREATED.
# Mount system to allow NVSI symlink
mount ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP /system rw
# Create NVSI filter symlink
symlink /data/data/com.nvidia.NvCPLSvc/files/com.nvidia.nvsiutilv1.xml /system/etc/permissions/com.nvidia.nvsiutilv1.xml
mount_all /fstab.cardhu
#chmod for OUYA parameters
chmod 0644 /dev/block/mmcblk0p5
Click to expand...
Click to collapse
After:
on fs
setprop ro.crypto.tmpfs_options size=128m,mode=0771,uid=1000,gid=1000
setprop ro.crypto.umount_sd false
# PLEASE DO NOT REMOVE NVSI SYMLINK! IF CHANGES ARE NEEDED PLEASE ENSURE THAT NVSI SYMLINK IS ALWAYS CREATED.
# Mount system to allow NVSI symlink
#mount ext4 /dev/block/sda2 /system rw
mount_all /fstab.cardhu
# Create NVSI filter symlink
symlink /data/data/com.nvidia.NvCPLSvc/files/com.nvidia.nvsiutilv1.xml /system/etc/permissions/com.nvidia.nvsiutilv1.xml
#chmod for OUYA parameters
chmod 0644 /dev/block/mmcblk0p5
Click to expand...
Click to collapse
Basically I commented out the mount command - before it was mounting system read/write for a moment to insert the symlink and let the filesystem update itself before remounting read-only in the fstab. The way I do it now it is simply mounted read/write from the fstab and left that way (some may consider this unsafe, but it is good for development... not too hard to remount it read-only if you so desire) I also shifted the symlink command down below the mount all command so it would hopefully still work... not sure what that was for, but they made it sound really important! XD
I also commented out this part about the usb drive since it doesn't really make sense anymore:
# Mount usb drives as /usbdrive. Generally usb drives are formatted with FAT
# filesystem, so we support FAT as of now.
#on device-added-/sys/block/sda
# mount vfat /dev/block/sda /mnt/usbdrive
Click to expand...
Click to collapse
I think those were all the changes I made before repacking it, though it did take me 5 attempts to get a working ramdisk so I may have lost track of something at some point. Those should be the key changes at least.
I also initially used raw dumps of the data and cache partitions on my thumb drive as well to make sure it would work. Then I tested to make sure it would work if they were empty ext4 partitions, which they do - Android fills them in as necessary. So only the system image was necessary to include. (and of course the boot.img for fastbooting)
This was a little bit harder than I had anticipated because I'd previously only looked into this type of thing for Gingerbread devices which aren't set up the same way. I'd kinda been hoping to get a solution where the user could just drop a system.img and data.img onto a fat32 usb thumb drive and the boot.img would loop mount them off the thumb drive. I haven't tried this for Gingerbread, but it seems pretty straightforward. It's not straightforward anymore here since fat32 sdcards aren't used anymore. Being familiar with Linux though, I am happy they are using ext4 everywhere and using the same space alloation for /data and /sdcard so you don't have to worry about which one to make big, but it does make some things more complicated for more average users. It's probably still possible to get the OUYA to do what I wanted, but more complicated and not sure it's worth pursuing over other methods which may be more fruitful.
Hope that's enough details to enlighten some people who may be wondering about the methods used here. My goal is to not only develop new ways of booting the OUYA, but also to share how I accomplished things so that others can learn from it.
~Troop

Is this similar to the Nook HD + CM10 boot?
---------- Post added at 05:07 AM ---------- Previous post was at 04:58 AM ----------
Wait that was blank a second ago. I am downloading now. I will mirro with my mediafir stuff if I can get it to work.

kairnage said:
Is this similar to the Nook HD + CM10 boot?
---------- Post added at 05:07 AM ---------- Previous post was at 04:58 AM ----------
Wait that was blank a second ago. I am downloading now. I will mirro with my mediafir stuff if I can get it to work.
Click to expand...
Click to collapse
Sorry, I was setting up the posts...
I'm not sure this is similar to any solution currently used on other devices, but I do know that other developers have used similar methods to develop their roms.
I don't have a Nook and haven't looked into what they use too much, but we may very well be able to learn from their work.
~Troop

So I dug up an old nvflash package from my Notion Ink Adam and tested it to make sure it still works (with the Adam in APX mode it allows me to directly flash the device with a new partition layout and flash the partitions directly). After verifying I had it setup correctly, I swapped the boot and recovery images and ran it again and sure enough... now when I boot my Adam normally, the recovery rom comes up, and when I boot my Adam into recovery it loads the normal rom - so the theory seems to work.
So I think the next thing I will try is building a new recovery for OUYA from source and adding an option to reboot into "recovery" to the menu, allowing it to be stored on the boot partition and the real boot.img to be stored on the recovery partition, allowing you to boot the OUYA and it comes up in recovery, then you select the new reboot option and it would reboot into "recovery" which would load a full rom. You could then safely flash boot images to the recovery partition without fear of bricking your device.
I think it should work nicely, but not sure how long it will take me since I need to set my build machine back up.
For those who are confused, read more about how these ideas started below!
~Troop
Trooper_Max said:
I think this is a great idea that needs more attention:
mybook4 said:
Devs, I propose the following to get rid of the potential brick risk:
Since we can't get into recovery manually (via HW buttons), let's reverse the role of SOS (recovery) and LNX (kernel). Since LNX is the booting kernel partition, let's flash recovery there and flash the kernel to the recovery partition. I believe we could do this by modifying the fstab and having our updater-scripts flash to the appropriate partitions.
From a cold start, a user will enter recovery (a minor inconvenience for safety). Depending on how we modify the recovery.fstab, getting to the ROM could be as simple as pressing power twice (recovery does a reboot system now and its fstab has the system actually reboot to the recovery partition, which is the ROM's kernel).
Definitely not straightforward, but should prevent bricks. Thoughts?
Sent from my Nexus 7 using xda premium
Click to expand...
Click to collapse
But then I'm definitely biased, because I had the same idea:
Trooper_Max said:
I agree with everyone it would be nice if we had a hardware means to boot into some kind of recovery or flashing mode to flash stock images.
But I was trying to think if there is anything we can do if we don't get that... (guess that makes me a pessimist >_>)
Let me preface this with don't try anything I'm describing here unless you know what you're doing, these are half-baked thoughts of someone who doesn't even have their OUYA yet:
What if we could swap the boot and recovery partitions? (I haven't received my OUYA yet, so I'm not even aware of what partitions it has, so assuming it has them, and yeah, it wouldn't be quite that simple)
Basically what I mean is when the device tries to boot normally, it would boot up a stable recovery rom. (ie the boot partition that normally has the kernel and then loads the rest of the rom instead just has a recovery rom)
Then you have the recovery partition be what boots the full rom. That way you only chance bricking your device when you flash the boot partition, which if we can get a stable recovery rom that works for this, wouldn't be often. We would probably want to modify the recovery to have a 3 second/configurable timer where if you don't do anything it boots into the "recovery" partition which would boot up the full rom.
Basically the boot partition becomes a new recovery rom which gets used like GRUB to boot into the "recovery" partition which boots up your actual rom, or maybe it could also boot from USB or netboot or whatever...
Pretty much what we need is a solid bootloader, sound about right? Let me know if any of this makes sense/doable or if I'm entirely off base here! I don't know if I will have the time to try any of this when I do get my OUYA, but wanted to share some ideas, please proceed at your own risk!
EDIT: Alternatively, the boot partition could be left stock and the recovery partition could be used as a bootloader to boot into USB or other options for loading roms without messing with the stock boot experience and risking bricking the device. ie in this configuration if you boot your device normally it would be stock, if you reboot into "recovery" it would load up a custom rom. Or instead of a custom rom, a custom recovery with bootloader capabilities.
~Troop
Click to expand...
Click to collapse
And I do plan to try this idea out eventually, but I've got some other ideas I intend to try out first.
The first one I hope to have done by the end of this weekend (hopefully sooner though) is to reconfigure this experimental CM build to be usable without touching any of the internal storage space. I plan to have a modified boot.img that will load system/data/sdcard folders off a usb thumb drive. This method would be completely safe, though a little inconvenient because you would need to use adb to reboot the OUYA into bootloader mode so that you can then fastboot it to load the modified boot.img, but after that it could be disconnected and would be running using only external storage. You're essentially using a computer to jumpstart your OUYA into CM10, while leaving everything on the OUYA itself in pristine stock condition. Then I plan to try out arm versions of adb/fastboot so I can use my tablet or possibly phone (USB OTG) to jumpstart the OUYA instead of having to rely on my computer all the time.
I think this will be an extremely safe way of using external ROMs until we can get some kind of special bootloader figured out.
So if anyone is thinking about trying CM10, but leery of messing with their OUYA, just wait another week or so and I should have a safe, non-intrusive solution worked out!
I welcome any input/thoughts on these ideas! And if anyone knows how to do the things I'm describing and wants to beat me to the punch, feel free and run with these ideas - I won't mind as long as you share your work and give me a little credit if any credit is due!
~Troop
Click to expand...
Click to collapse

I just ordered a 64GB PNY off Amazon. Once I get it Tuesday I am going to try this. I am uploading to my mediafire now to mirror.

Trooper_Max said:
So I dug up an old nvflash package from my Notion Ink Adam and tested it to make sure it still works (with the Adam in APX mode it allows me to directly flash the device with a new partition layout and flash the partitions directly). After verifying I had it setup correctly, I swapped the boot and recovery images and ran it again and sure enough... now when I boot my Adam normally, the recovery rom comes up, and when I boot my Adam into recovery it loads the normal rom - so the theory seems to work.
Click to expand...
Click to collapse
After some more playing with my Adam, I noticed that when I reboot into "recovery" which I have booting a CyanogenMod rom and then I reboot and from the reboot menu select "Reboot", it reboots into CyanogenMod again (even though I didn't expect it to). From the reboot menu I tell it to reboot into "recovery" and it boots into CM again, which that part makes sense, since I have the CM boot image stored in the recovery partition. So I got to thinking that maybe when you tell it to reboot into recovery it sets an SOS signal (the recovery partition is sometimes refered to as SOS) and when you boot a normal rom from recovery, it never clears that signal because it isn't normally booting that way. Whereas a true recovery rom knows it needs to clear that signal so you don't get stuck booting into the recovery rom all the time.
I was close - I scanned the recovery source on CM's github and found this bit:
https://github.com/CyanogenMod/android_bootable_recovery/blob/jellybean/recovery.c said:
// Reset to normal system boot so recovery won't cycle indefinitely.
struct bootloader_message boot;
memset(&boot, 0, sizeof(boot));
set_bootloader_message(&boot);
Click to expand...
Click to collapse
So there seems to be a "bootloader message" that tells it whether to boot from the boot or recovery partition. I was going to say we need to be careful how we reboot the device and probably modify the custom rom to be able to reset the boot message, but I just realized we can do better and use this to our advantage. We could set our custom rom to always clear the boot message so that you have to go through the recovery rom each time to boot the system normally, but we could also have the option of selectively resetting the bootloader message - purposefully get ourselves stuck rebooting into "recovery" all the time because that is our normal rom, then from our normal rom have the option of resetting the bootloader message when we want to go into our recovery image stored on the boot partition.
Something to think about - I don't like getting stuck out of my recovery image either, so we gotta be sure we can reset the bootloader message when we need to... I'm going to play with this some more tomorrow, but not sure how far I will get.
EDIT: More info on the bootloader message - seems it is stored on the misc partition. The more I think about this too, the more I'm not sure swapping the boot/recovery is much safer - if we had them swapped, but then the rom gets stuck in a boot loop before it can reset the bootloader message, we'd be stuck always booting into "recovery" and into the boot loop, so we'd be in just as much trouble as if we'd gotten our boot partition to cause boot loops. So whereas normally flashing the boot partition is potentially dangerous, in this scenario flashing the recovery partition would be potentially dangerous - you gotta be sure it's going to be able to reset the bootloader message. We could try to mitigate this by modifying the boot process to reset the bootloader message very early in the boot process (ie before the potential bootloop) so that if we get stuck, the next time we reboot, we'll reboot normally into the recovery rom.
But then we could also do just the opposite of that without swapping the boot/recovery partitions - very early in the boot process, modify the bootloader message to tell the bootloader to boot into recovery - that way if we get stuck the next time we boot up will be into recovery. Then later when the system successfully boots, we could reset the bootloader message so that after a successful boot the next boot will be another normal one instead of into recovery. If we get this right a failed boot would automatically take us to recovery on the next boot, while a successful boot would boot normally on the next boot. So this would be a way to build in some "brick-protection" into the boot.img to make it safer to flash. It'd probably be safest to not reset the bootloader message until the user actually selects the shutdown option - that way any abnormal reboot would cause it to come up into recovery mode.
So I'm not sure swapping boot/recovery partitions really buys us anything anymore, since it also swaps which partition is potentially dangerous to flash. The solution in either case is going to be to cleverly manipulate the bootloader message as described above. So we might just want to not swap them to minimize confusion and focus instead on building "brick-protection" like this into our boot images.
https://github.com/CyanogenMod/android_bootable_recovery/blob/jellybean/bootloader.h said:
/* Bootloader Message
*
* This structure describes the content of a block in flash
* that is used for recovery and the bootloader to talk to
* each other.
*
* The command field is updated by linux when it wants to
* reboot into recovery or to update radio or bootloader firmware.
* It is also updated by the bootloader when firmware update
* is complete (to boot into recovery for any final cleanup)
*
* The status field is written by the bootloader after the
* completion of an "update-radio" or "update-hboot" command.
*
* The recovery field is only written by linux and used
* for the system to send a message to recovery or the
* other way around.
*/
struct bootloader_message {
char command[32];
char status[32];
char recovery[1024];
};
/* Read and write the bootloader command from the "misc" partition.
* These return zero on success.
*/
int get_bootloader_message(struct bootloader_message *out);
int set_bootloader_message(const struct bootloader_message *in);
Click to expand...
Click to collapse
kairnage said:
I just ordered a 64GB PNY off Amazon. Once I get it Tuesday I am going to try this. I am uploading to my mediafire now to mirror.
Click to expand...
Click to collapse
Sounds nice - I'm tempted to get a nice big new thumb drive myself... I don't have any that big >_>
~Troop

I've been following your think tank and I agree with your latest idea 100%
Sending a message for bootloader to always boot into recovery if the system wasn't shut down normally is clean and simple.
I am curious though what about development, with nvflash requiring encryption of commands first mistake will render your ouya unusable.

dexter84 said:
I've been following your think tank and I agree with your latest idea 100%
Sending a message for bootloader to always boot into recovery if the system wasn't shut down normally is clean and simple.
I am curious though what about development, with nvflash requiring encryption of commands first mistake will render your ouya unusable.
Click to expand...
Click to collapse
Glad you agree with my new idea!
As far as development, yeah, that is why I used my Notion Ink Adam for some of the testing that I did.
As far as developing for OUYA, I don't think we are limited by not having nvflash, we just have to be more careful. Personally, if I were developing anything, I would use my above methods to fastboot boot images that load everything else from a thumb drive at least until whatever I'm developing becomes stable enough that I want to use it more permanently. Then I would be very careful about how I flash it.
Heck, if you wanted to be really safe, you could flash recovery images to both the boot and recovery partitions and just use external boot methods
In the long term though, I hope we can develop a bootloader based on the kexec hardboot patches for the original Nexus 7, which would allow booting completely off boot images stored in other locations, loading partitions from other locations. Other locations could even just be the virtual sd card if you don't want to use external media, but at that point we'd have a safe extra bootloader stored on the boot partition.
http://forum.xda-developers.com/showthread.php?t=2104706
Hope that makes sense.
~Troop

I was not aware that any content of RAM can survive a reboot, hard kexec booting custom OS from USB or image is definitely a safe solution, looks like all the pieces are there.
Wish I had something more than ouya alone, since you have your Adam are you going to try to develop something ?

dexter84 said:
I was not aware that any content of RAM can survive a reboot, hard kexec booting custom OS from USB or image is definitely a safe solution, looks like all the pieces are there.
Wish I had something more than ouya alone, since you have your Adam are you going to try to develop something ?
Click to expand...
Click to collapse
I do intend to, but I don't have a great deal of time to devote to Android development, so not sure how long it will take me. I'm trying to find what time I can though. This past weekend/last week I had a bit more than usual.
~Troop

Trooper_Max said:
http://troopermax.com/releases/ouya-sda123-boot.zip
(be gentle - it's 145 MB, I use shared hosting, so feel free to mirror)
md5sum: 49c8e16e27b6deb9d1e8e86363b56f2f
~Troop
Click to expand...
Click to collapse
Here is a mirror for you.
http://www.mediafire.com/download/hban76kzeys6ybd/ouya-sda123-boot.zip
I tried this on my new 64GB and it wouldn't boot, but it's a brand new card so it might be the problem. I'll try a known good card later.

kairnage said:
Here is a mirror for you.
http://www.mediafire.com/download/hban76kzeys6ybd/ouya-sda123-boot.zip
I tried this on my new 64GB and it wouldn't boot, but it's a brand new card so it might be the problem. I'll try a known good card later.
Click to expand...
Click to collapse
Sorry you had trouble - a couple other things to be wary of:
Have only the one thumb drive connected, at least until it boots - the boot.img looks for the data partition as sda1, the system partition as sda2, and the cache partition as sda3. If some other storage device is connected, it might be labeled sda by the OUYA depending on the order it finds them in and then the thumb drive might become sdb or so on.
It worked for me through a hub, but it may also be worth trying it directly if you have trouble.
Guessing you did this, but give it some time, booting from thumb drive especially on the first boot is slower. It's not too long, but it was long enough that for a moment I thought I'd failed again. Of course the thumb drive I was using wasn't built for speed, so YMMV.
If you're still having trouble - even on my failed attempts at boot images for this (it took me 5 tries at getting the ramdisk to get it bootable), I was still able to connect to it using adb. I ran adb on Linux, running adb as root to bypass all that udev configuration stuff - it's just easier, and if the OUYA/device failed to mount the system partition, it might not match the configuration you expect anyway. If you're able to run "adb shell" but it gives you a permission error about not being able to access the shell binary on the system partition, that probably means you didn't setup the system partition correctly - it's crucial that it get set up with the right permissions, which is why I provided the image so it could just be written directly with dd.
I'm going to try to put together a recovery image that can partition the thumb drive for you and flash an arbitrary update.zip to the thumb drive, but not sure when I will be able to have that ready. The initial version will not be able to patch the boot.img though, so that will still need to be modified like the one I have provided, but maybe in a future version I can get it to also modify the boot.img for loading the information from the thumb drive.
Let me know if you continue to have issues or if you do get it working! And if anyone else has got it working, please post so I can at least know someone got it working. It worked for me, and I don't see why it shouldn't work for anyone else, but if there is something conflicting I want to figure it out.
EDIT: I just remembered when I was looking into the swapping boot/recovery stuff, I noticed in the recovery source that there already are some tools that might be able to help partition the thumb drive and fix permissions included in the recovery source:
https://github.com/CyanogenMod/android_bootable_recovery/tree/jellybean/utilities
Tonight I'll see if I can put together some new instructions using those tools that might be easier and less error-prone. I'm hoping those tools can be applied to the thumb drive anyway, I'll try and figure that out tonight.
~Troop

Trooper_Max said:
Sorry you had trouble - a couple other things to be wary of:
Have only the one thumb drive connected, at least until it boots - the boot.img looks for the data partition as sda1, the system partition as sda2, and the cache partition as sda3. If some other storage device is connected, it might be labeled sda by the OUYA depending on the order it finds them in and then the thumb drive might become sdb or so on.
It worked for me through a hub, but it may also be worth trying it directly if you have trouble.
Guessing you did this, but give it some time, booting from thumb drive especially on the first boot is slower. It's not too long, but it was long enough that for a moment I thought I'd failed again. Of course the thumb drive I was using wasn't built for speed, so YMMV.
If you're still having trouble - even on my failed attempts at boot images for this (it took me 5 tries at getting the ramdisk to get it bootable), I was still able to connect to it using adb. I ran adb on Linux, running adb as root to bypass all that udev configuration stuff - it's just easier, and if the OUYA/device failed to mount the system partition, it might not match the configuration you expect anyway. If you're able to run "adb shell" but it gives you a permission error about not being able to access the shell binary on the system partition, that probably means you didn't setup the system partition correctly - it's crucial that it get set up with the right permissions, which is why I provided the image so it could just be written directly with dd.
I'm going to try to put together a recovery image that can partition the thumb drive for you and flash an arbitrary update.zip to the thumb drive, but not sure when I will be able to have that ready. The initial version will not be able to patch the boot.img though, so that will still need to be modified like the one I have provided, but maybe in a future version I can get it to also modify the boot.img for loading the information from the thumb drive.
Let me know if you continue to have issues or if you do get it working! And if anyone else has got it working, please post so I can at least know someone got it working. It worked for me, and I don't see why it shouldn't work for anyone else, but if there is something conflicting I want to figure it out.
EDIT: I just remembered when I was looking into the swapping boot/recovery stuff, I noticed in the recovery source that there already are some tools that might be able to help partition the thumb drive and fix permissions included in the recovery source:
https://github.com/CyanogenMod/android_bootable_recovery/tree/jellybean/utilities
Tonight I'll see if I can put together some new instructions using those tools that might be easier and less error-prone. I'm hoping those tools can be applied to the thumb drive anyway, I'll try and figure that out tonight.
~Troop
Click to expand...
Click to collapse
I could get into ADB as well but was only seeing the stock system. Actually now I think it was the adapter I was using. At first I assumed it was the microsd because it would hang on boot. But after trying a known good card it did the same. I remembered having issues with an adapter that has the indicator light to show it was connected on a tablet before. I tried a generic Kingston adapter and it sees the cards now. Of course I had already wiped them back to stock partitions. LOL Oh well, start again tomorrow.

For anyone who doen't have a Linux box handy or an extra thumb drive to boot a live USB, here are some quick instructions on how to partition the thumb drive from the OUYA itself. You can connect the thumb drive either before or after booting, it doesn't really matter. I'm using all fastboot/adb commands here so they are easy to recognize. If you're knowledgeable about how to use adb/fastboot, feel free to execute the commands however you're comfortable.
Type all the adb/fastboot commands as specified - if it doesn't begin with adb or fastboot, it isn't a command. All /dev paths you type into the commands should be related to /dev/block/sda (your thumb drive), not any internal partitions or you could mess up your OUYA!!!
Boot up the OUYA normally, then reboot into the bootloader:
adb reboot bootloader
Boot CWM using fastboot:
fastboot boot OuyaCWMrecovery6.0.3.2.img
Print partition information for the thumb drive:
adb shell parted /dev/block/sda print
Model: USB Flash Memory (scsi)
Disk /dev/block/sda: 8128MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 32.3kB 6000MB 6000MB primary ext4
2 6000MB 7000MB 1000MB primary ext4
3 7000MB 8000MB 1000MB primary ext4
Click to expand...
Click to collapse
(note in the example output above I already have it partitioned)
Here I was using an 8 GB thumb drive, you can see the size where it says 8128MB.
Delete Partitions from thumb drive: (be sure you don't have anything important on your thumb drive)
adb shell parted /dev/block/sda rm 1
adb shell parted /dev/block/sda rm 2
adb shell parted /dev/block/sda rm 3
(note that you only need to delete partitions that showed up in the table when you printed it, here I deleted 1,2,3, since I had 3 partitions above and the parted commands will say you may need to update your fstab, but that is not relevant here so don't worry about it)
Create 3 primary partitions (adjust the sizes as necessary):
adb shell parted /dev/block/sda mkpart primary 1 6000
adb shell parted /dev/block/sda mkpart primary 6000 7000
adb shell parted /dev/block/sda mkpart primary 7000 8128
Check your paritions again:
adb shell parted /dev/block/sda print
Format your partitions as ext4:
adb shell mke2fs -t ext4 /dev/block/sda1
adb shell mke2fs -t ext4 /dev/block/sda2
adb shell mke2fs -t ext4 /dev/block/sda3
Push the cm10 system image onto the device: (this will take a little while)
adb push ouya-cm10-system.img /tmp/ouya-cm10-system.img
Check that it copied correctly:
adb shell ls -l /tmp
-rw-rw-rw- 1 root root 260308992 Jul 27 2013 ouya-cm10-system.img
-rw-rw-rw- 1 root root 3587 Jan 1 02:12 recovery.log
Click to expand...
Click to collapse
(Note the size... I'm pretty sure copying it /tmp put it into the ramdisk, but our OUYA has enough ram for this)
Write the cm10 system image onto /dev/block/sda2: (this will take a little while)
adb shell dd if=/tmp/ouya-cm10-system.img of=/dev/block/sda2 bs=4M
Check/fix the filesystem:
adb shell e2fsck -fp /dev/block/sda2
Resize the filesystem to fill the partition:
adb shell resize2fs /dev/block/sda2
(Unfortunately, it looks like resize2fs is not included in CWM, so this step would need to be done on the computer)
At this point, the thumb drive should be good, so you just gotta reboot back to the bootloader and boot the boot image:
Reboot to the bootloader again:
adb reboot bootloader
Boot the modified boot image I provided:
fastboot boot ouya-sda123-boot.img
Not sure if that's necessarily easier or harder to follow than the other instructions... I'd probably rather do the partitioning on a desktop with GUIs, but for some who don't have a Linux box handy it might be easier to use the OUYA as a little Linux box
I'm sure you noticed this method still used dd to write the system image, just run from the OUYA instead. I looked into just extracting the system files from the CM10 zip onto the OUYA, but fixing the permissions was not as easy as I thought it would be - the /system partition permissions are actually fixed by the updater script as referred to here:
http://fokke.org/site/content/howto-create-android-updatezip-package
It's actually a scripting language and the script also creates symlinks and does other stuff.
You'd have to extract/modify the updater script to not use the internal partitions and then execute it (I think using the edify program)... still less straightforward than using dd if you have the image handy like I gave you... But I may look into this as another option. The knowledge will certainly be relevant when I look to build a custom CWM recovery to allow you to flash zips to the thumb drive instead of the internal partitions.
~Troop

Thanks to csonger for feedback, which may be handy if you have system partition issues:
csonger said:
I tried both methods (under linux and with ouya as well), but neither of them worked for me. My 8 gig pen couldn't boot.
The first thing is that the system image is 256MB and the tutorial says the System partition needs 512MB or 1GB.
After the boot failures I checked the pendrive. The second (system) partition was 256MB. It is ok when we use dd, but it was full. 100% usage.
First I run the e2fsck command to check for filesystem problems and it found some inode issues on it.
Following the fs fix the resize2fs command did the job and I had got a 1 gig System partition.
After that my pendrive could boot the cyanogenmod image without problems.
May be someone else has the same problem as me. Please share with them.
Thanks for your work:
csonger
Click to expand...
Click to collapse
I didn't have those issues myself for some reason, but I'll investigate and see what instructions I need to update!
Thanks again for the feedback!
~Troop

Finally got my Linux partition back up and running so I can give this a go again.

It's been trying to boot CM for about 15 minutes now, ADB does see it, but I think it might no like the partitions I did.I did 2GB for system and 1GB for cache. I will repartition and try again.

kairnage said:
It's been trying to boot CM for about 15 minutes now, ADB does see it, but I think it might no like the partitions I did.I did 2GB for system and 1GB for cache. I will repartition and try again.
Click to expand...
Click to collapse
That should be fine, I would think... If you continue to have trouble, try running e2fsck and resize2fs on the system partition, as csonger suggested. (In case you didn't already)
I was confused when I came up with the instructions that it worked without me doing resize2fs since I figured that would be needed to expand the filesystem to fill the partition, but somehow it worked anyway and even looked like it was expanded, but I'd probably just forgot to refresh my view after dd.
Note that you can run the commands with just the partition as an argument: (I added -fp to e2fsck to automatically find/fix problems)
e2fsck -fp /dev/sdX2
resize2fs /dev/sdX2
(Where X is the letter for your thumb drive)
Without a size specified, resize2fs resizes the filesystem to fill the partition.
Hope that helps!
EDIT: I went back and fixed the instructions with this addition now that I've tested it a little more. Unfortunately, I noticed that CWM does not include resize2fs and I didn't spot any other programs handy within CWM to do the trick, so you can't quite do this part on the OUYA. I will look into alternate instructions or building my own CWM that includes resize2fs or just plain automates this more.
~Troop

[Q] Cant get MB886 into custom recovery

I have been trying for hours to install a custom recovery in my AT&T Atrix HD (mb886) phone. Every time I go through the flashing process, no matter what recovery I try, and whether I use the stock SDK fastboot or one of alternatives, when I try to boot into recovery, I get an ominous error message about how my bootloader is unlocked, and Motorola and ATT will not honor the warranty, and so on. However - it then always boots into the normal startup. I did try holding down both volume buttons when I cycled the power button, and I briefly (about 5 seconds, maybe?) got what looked like a text-based recovery menu, but then the error message popped up again, and I'm back to ????? is going on.
Any help? I have read a number of article/forums online, but all assume that your recovery is working so you can install a custom ROM. I have done this on a couple of Android tablets in the past, so I know I'm not totally stupid, but I can't seem to get past the AT&T nanny.
How can I fix this?
Android 4.1.1
System 98.4.20.MB886.ATT.en.US

If I remember correctly, I had to rename install-recovery.sh (or something like that) by adding .bak to the end of the filename. Boot into fastboot, flash your recovery, and try to boot into recovery.

Nevadadave said:
I have been trying for hours to install a custom recovery in my AT&T Atrix HD (mb886) phone. Every time I go through the flashing process, no matter what recovery I try, and whether I use the stock SDK fastboot or one of alternatives, when I try to boot into recovery, I get an ominous error message about how my bootloader is unlocked, and Motorola and ATT will not honor the warranty, and so on. However - it then always boots into the normal startup. I did try holding down both volume buttons when I cycled the power button, and I briefly (about 5 seconds, maybe?) got what looked like a text-based recovery menu, but then the error message popped up again, and I'm back to ????? is going on.
Any help? I have read a number of article/forums online, but all assume that your recovery is working so you can install a custom ROM. I have done this on a couple of Android tablets in the past, so I know I'm not totally stupid, but I can't seem to get past the AT&T nanny.
How can I fix this?
Android 4.1.1
System 98.4.20.MB886.ATT.en.US
Click to expand...
Click to collapse
That warning you see is just the boot logo and can be gotten rid of by flashing a custom logo. Stock Moto boot logos on this platform have two images -- one for locked and another for unlocked bootloaders. It's a non issue and just confirms that the bootloader is unlocked.
You accessed that menu by powering up and holding both volumes and power. Volume down scrolls and volume up selects in there.
To install a custom recovery, boot into fastboot mode and flash it with fastboot. Mythtools, maybe BootMyHD, can do that for you if you don't have moto-fastboot binary or are unable to run "moto-fastboot flash recovery recovery.img" with your phone plugged into a rear usb port in fastboot mode with a terminal/command prompt open to the directory with the recovery image.

More questions
audit13, how do I access that file to change the name? I tried again this morning, and after doing the boot to recovery key sequence, I got a menu, and before it went away, I selected boot to recovery, but got the dead android icon. I tried several other options and it just did a normal boot. Still stumped.
skeevydude, I have tried installing a couple of custom recoveries, using fastboot, and when I do, I get a message saying all went well, but when I boot up, it either does the "failed Android" or just boots up normally. I'll try Mythtools and BootMyHD, but it seems that there is something else going on here.

Nevadadave said:
audit13, how do I access that file to change the name? I tried again this morning, and after doing the boot to recovery key sequence, I got a menu, and before it went away, I selected boot to recovery, but got the dead android icon. I tried several other options and it just did a normal boot. Still stumped.
skeevydude, I have tried installing a couple of custom recoveries, using fastboot, and when I do, I get a message saying all went well, but when I boot up, it either does the "failed Android" or just boots up normally. I'll try Mythtools and BootMyHD, but it seems that there is something else going on here.
Click to expand...
Click to collapse
Maybe something else going on. Are you flashing using the rear usb port of your PC? It really does matter.
To answer the first question about install-recovery, once you're rooted, use Root Explorer or something similar, mount /system as read/write, go to /system/etc, rename the file install-recovery.sh to install-recovery.sh.bak, and reboot.
If you have adb installed on your PC you can do
adb root
adb shell mount -o remount,rw /system
adb shell cp /system/etc/install-recovery.sh /system/etc/install-recovery.sh.bak
adb shell rm /system/etc/install-recovery.sh
adb reboot

I'll try it and see what happens
skeevydude said:
Maybe something else going on. Are you flashing using the rear usb port of your PC? It really does matter.
To answer the first question about install-recovery, once you're rooted, use Root Explorer or something similar, mount /system as read/write, go to /system/etc, rename the file install-recovery.sh to install-recovery.sh.bak, and reboot.
If you have adb installed on your PC you can do
adb root
adb shell mount -o remount,rw /system
adb shell cp /system/etc/install-recovery.sh /system/etc/install-recovery.sh.bak
adb shell rm /system/etc/install-recovery.sh
adb reboot
Click to expand...
Click to collapse
OK, I did not know about USB port preference. I'll try it and see what happens. Thanks!

No joy
Nevadadave said:
OK, I did not know about USB port preference. I'll try it and see what happens. Thanks!
Click to expand...
Click to collapse
Well, I tried front and back USB ports, in all cases, adb says "adb can't run as root in production builds". adb sees the phone, but about all I can do is start fastboot, but once there adb doesn't work until I reboot.
I tried running the remount command, but got a message, "Operation not permitted" I'm assuming because I could not root into the phone. Titanium backup shows that the phone is, indeed, rooted.
Stuck again...

Install Root Explorer, find the file, add .bak to the end, reboot to fastboot, install Philz, boot into recovery.

audit13 said:
Install Root Explorer, find the file, add .bak to the end, reboot to fastboot, install Philz, boot into recovery.
Click to expand...
Click to collapse
I tried that, got a "Rename failed". It appears that the file is set to read-only, and the Root Explorer doesn't seem to have a way to change that. I'm open to additional suggestions. I had thought that root access would allow me to do things like change file permissions, but I cannot do this with Root Explorer. Everything I try, I get a message that it can't be done, because the file system is read-only.
At the top of the file list, it says "mounted as r/o, but nothing shows to change that, although I see num,erous web posts that claim that there should be a "R/W" button somewhere.

Better luck
Nevadadave said:
Well, I tried front and back USB ports, in all cases, adb says "adb can't run as root in production builds". adb sees the phone, but about all I can do is start fastboot, but once there adb doesn't work until I reboot.
I tried running the remount command, but got a message, "Operation not permitted" I'm assuming because I could not root into the phone. Titanium backup shows that the phone is, indeed, rooted.
Stuck again...
Click to expand...
Click to collapse
OK, I dropped Root Explorer and loaded ES File Explorer. ES Explorer allowed me to change the file R/W permissions and rename the stock recovery file.
adb would still not allow me to get to root, so I loaded adbd insecure from the Play store, and that gave me root access. I flashed the CWR 6.0.4.4, and so far (fingers crossed) I was able to boot to CWM and I'm backing up my system now. Hopefully, the next update will be to say that I have a new ROM installed...

Nevadadave said:
OK, I dropped Root Explorer and loaded ES File Explorer. ES Explorer allowed me to change the file R/W permissions and rename the stock recovery file.
adb would still not allow me to get to root, so I loaded adbd insecure from the Play store, and that gave me root access. I flashed the CWR 6.0.4.4, and so far (fingers crossed) I was able to boot to CWM and I'm backing up my system now. Hopefully, the next update will be to say that I have a new ROM installed...
Click to expand...
Click to collapse
All you need to gain r/w access is to click on the ro button to change it to read/write.

audit13 said:
All you need to gain r/w access is to click on the ro button to change it to read/write.
Click to expand...
Click to collapse
Audit13 I'm not sure what you mean here. Root Explorer never indicated a "R/O" button or any other way to change permissions, it just kept saying that the file system was write-protected. ES File Explorer was very easily able to change this and allow me to remove the automatic recovery overwrite.
So, at this point, I have Cyanogen 10.2 running on my Atrix HD, and although I have found a few glitches, it is faster and it is now MINE!

Nevadadave said:
Audit13 I'm not sure what you mean here. Root Explorer never indicated a "R/O" button or any other way to change permissions, it just kept saying that the file system was write-protected. ES File Explorer was very easily able to change this and allow me to remove the automatic recovery overwrite.
So, at this point, I have Cyanogen 10.2 running on my Atrix HD, and although I have found a few glitches, it is faster and it is now MINE!
Click to expand...
Click to collapse
In Root Explorer, You'll see the words "Mounted as r/o". To the right will be a button that says "Mount R/W".
I went with Validus 5.1 over 10.2.