Database Develop

[INFO] Clockworkmod for Arc

So just to start off this topic with any insight in cwm for this unit.
As far as I know, under fastboot mode, there is a way to flash an update.zip:
C:\Users\user>fastboot
usage: fastboot [ <option> ] <command>
commands:
update <filename> reflash device from update.zip
flashall flash boot + recovery + system
flash <partition> [ <filename> ] write a file to a flash partition
erase <partition> erase a flash partition
getvar <variable> display a bootloader variable
boot <kernel> [ <ramdisk> ] download and boot kernel
flash:raw boot <kernel> [ <ramdisk> ] create bootimage and flash it
devices list all connected devices
continue continue with autoboot
reboot reboot device normally
reboot-bootloader reboot device into bootloader
options:
-w erase userdata and cache
-s <serial number> specify device serial number
-p <product> specify product name
-c <cmdline> override kernel commandline
-i <vendor id> specify a custom USB vendor id
-b <base_addr> specify a custom kernel base address
-n <page size> specify the nand page size. default:
2048
C:\Users\user>
So perhaps, that can work to flash a cwm when it's built?

It would nice to see cwm on Arc. but we finally got root so this will come to and more custom roms

Fastboot update.zips are different to the ones for recoveries.

When I listed out the partition mapping on the device, I do not see any recovery partition on the unit though:
# df
df
Filesystem Size Used Free Blksize
/dev 167M 76K 167M 4096
/mnt/asec 167M 0K 167M 4096
/mnt/obb 167M 0K 167M 4096
/system 312M 213M 98M 4096
/data 380M 216M 163M 4096
/cache 225M 7M 217M 4096
/data/idd 10M 1M 8M 4096
/mnt/sdcard 31G 3G 27G 32768
/mnt/secure/asec 31G 3G 27G 32768
# cat /proc/mtd
cat /proc/mtd
dev: size erasesize name
mtd0: 13880000 00020000 "system"
mtd1: 00a00000 00020000 "appslog"
mtd2: 0e100000 00020000 "cache"
mtd3: 17c00000 00020000 "userdata"

yes device may not have recovery partition
however we can always stick to xrecovery attempt do we not?

Did you try to download Clockwork mod from market and install recovery from the app itself?

or we could just build a "fastboot boot"able recovery. Y'know, no actual "real" one on the phone itself but we can always tetherboot a recovery!

We have to talk to Amon Ra and xrecovery guys

What does CWM have that xrecovery doesn't?

im_iceman said:
What does CWM have that xrecovery doesn't?
Click to expand...
Click to collapse
Ability to run when /system partition is empty/missing files.

blagus said:
Ability to run when /system partition is empty/missing files.
Click to expand...
Click to collapse
well thats bound to happen since xrecovery/freexperia recovery works from /system rather than CWM which runs from recovery partition...

Sure, CWM recovery will never work on SE model device.
Sent from my LT15i using XDA Premium App

why won't it work?

becuse SE do not have recovery partition.
Sent from my LT15i using XDA Premium App

keijames said:
becuse SE do not have recovery partition.
Sent from my LT15i using XDA Premium App
Click to expand...
Click to collapse
Sothe question here is.. How does a Arc restore its data during a factory reset?

Possibly clear /data and dalvik-cache, etc.

keijames said:
becuse SE do not have recovery partition.
Sent from my LT15i using XDA Premium App
Click to expand...
Click to collapse
How about creating a recovery partition now that we have root access? or is it practically impossible? probably a stupid question but its better to ask than wonder

Juevani said:
How about creating a recovery partition now that we have root access? or is it practically impossible? probably a stupid question but its better to ask than wonder
Click to expand...
Click to collapse
That's theoretically speaking possibile with repartitioning, but it can screw up your device pretty bad when you do it wrong...

Thijs96 said:
That's theoretically speaking possibile with repartitioning, but it can screw up your device pretty bad when you do it wrong...
Click to expand...
Click to collapse
Plus, how to add possibility of booting into recovery in bootloader?

Thijs96 said:
That's theoretically speaking possibile with repartitioning, but it can screw up your device pretty bad when you do it wrong...
Click to expand...
Click to collapse
but how can it screw up the device? partitioning is possible so I cant see where the problem is. Remember that Sony most have had some kinda of partitioning and recovery in first place to get the OS into the device, correct me if Im wrong.

Which partition is equal to /recovery in other android devices?

I am new to Android, want to customize the system follow the tutorials, but found the Note is different to other Android phones:
for other phone, there will be a /proc/mtd and list all the partitions with mount point, but on Note I can only found /proc/fs, with 3 folders: ext4 jbd2 nfsd
and the mount table is like this:
rootfs on / type rootfs (ro,relatime)
...
/dev/block/mmcblk0p9 on /system type ext4
/dev/block/mmcblk0p7 on /cache type ext4
/dev/block/mmcblk0p1 on /efs type ext4
for other devices, e.g., HTC Wildfire, the partition will like below:
mtd1: recovery
mtd3: system"
...
I downloaded the CF-Root flasher, by Chainfire, found basiclly it's flashing a zImage into /dev/block/mmcblk0p5. I mount the partition before flash and seems there is only some picture files there. how can we know the machine will boot to this partition in recovery mode?

nobody knows? so far what I get seems that the phone do not use the /recovery partition, but use same kernel to handle the recovery state. during boot it will search for /system/etc/install-recovery.sh, maybe that will trigger the recovery process?

The Note, like many other Samsung phones, does not use or follow the mtd layout - at all.
Indeed there is a single kernel for both normal boot and recovery. Normal boot uses init.rc script, recovery boot uses recovery.rc script.
There is a "spare" partition that is both called recovery and available, but it isn't used.

[High experimental] CM10 for new ICS Bootloader and Layout

Hello
in the CallBug Thread wrote any User can be flash CM10 on the new Layout. I replaced any in the updater-script in META-INF...
to its work you need
- Topogigis LGP990-ICS28G_TG or a another ICS with new unlocked Bootloader and new Layout and CWM 6
No i worked hard and first Tests says it can works. I tested it with the Kernel from Topogigi_SP2_ICS28G_20121126... I see the Bootscreen. Next step i test it with the Kernel form CallBugThread... I see only the LG Logo.
Next i test it with the boot.img from LGP990_ICS_v28G_Stock_NewBL_Root_CWM_initd_NVFlash
in the Moment i dont see the Starts Wizard
Now i must first do following:
In CWM go to mount and storage and format: system, data, cache manually
wipe Data/Cache (factory-reset) is not enough
a success boot to start wizard works only when any can make a Kernel. In the Moment, all available Kernel is not enough
in the Attachment the Updaterscript
pengus77 have made a step by step guide for work CM10 with the new Bootloader and Layout
pengus77 said:
So... here comes the step-by-step sum up guide to boot cm10 on the new bootloader !
1) Edit BoardConfig.mk in device/lge_p990/lge_p990 and replace
Code:
BOARD_SYSTEMIMAGE_PARTITION_SIZE := 665681920
BOARD_USERDATAIMAGE_PARTITION_SIZE := 1170259968
with
Code:
BOARD_SYSTEMIMAGE_PARTITION_SIZE := 536870912
BOARD_USERDATAIMAGE_PARTITION_SIZE := 1610612736
then add this line
Code:
TARGET_USERIMAGES_SPARSE_EXT_DISABLED := true
and replace this other one
Code:
BOARD_VOLD_MAX_PARTITIONS := 10
with
Code:
BOARD_VOLD_MAX_PARTITIONS := 20
2) Edit, in the same folder, the file init.p990.rc and fix it so that it looks like this
Code:
# mount partitions
mount ext4 /dev/block/mmcblk0p12 /system wait
mount ext4 /dev/block/mmcblk0p12 /system ro noatime remount barrier=1 wait
# We chown/chmod /data again so because mount is run as root + defaults
mount ext4 /dev/block/mmcblk0p9 /data nosuid nodev noatime barrier=1 wait
chown system system /data
chmod 0771 /data
mount ext4 /dev/block/mmcblk0p2 /cache nosuid nodev noatime barrier=1 wait
chown system cache /cache
chmod 0770 /cache
mount ext3 /dev/block/mmcblk0p7 /lgdrm nosuid nodev noatime
3) Edit, always there, the file vold.fstab
Code:
dev_mount sdcard /storage/sdcard1 auto /devices/platform/sdhci-tegra.2/mmc_host/mmc1
dev_mount emmc /storage/sdcard0 11 /devices/platform/sdhci-tegra.3/mmc_host/mmc0
4) Edit (yeah same folder, same folder) the file recovery.fstab (don't know for sure if it's needed but here we go...)
Code:
# mount point fstype device [device2] fstype2
/recovery emmc /dev/block/mmcblk0p8
/boot emmc /dev/block/mmcblk0p6
/cache ext4 /dev/block/mmcblk0p2
/data ext4 /dev/block/mmcblk0p9
/external_sd vfat /dev/block/mmcblk1p1
/sdcard vfat /dev/block/mmcblk0p11
/system ext4 /dev/block/mmcblk0p12
5) Go to kernel/lge/star/arch/arm/configs/cyanogenmod_p990_defconfig and replace this line
Code:
CONFIG_CM_BOOTLOADER_COMPAT=y
with this
Code:
CONFIG_CM_BOOTLOADER_COMPAT=n
6) Edit kernel/lge/star/arch/arm/mach-tegra/lge/star/include/lge/board-star-nv.h and replace
Code:
#define LGE_NVDATA_PARTITION "/dev/block/mmcblk0p3"
with
Code:
#define LGE_NVDATA_PARTITION "/dev/block/mmcblk0p5"
7) In device/lge/star-common/init.cm-star.rc modify this (at about line 120)
Code:
chmod 777 /dev/block/mmcblk0p3
chmod 644 /dev/block/mmcblk0p5
into this
Code:
chmod 777 /dev/block/mmcblk0p5
chmod 644 /dev/block/mmcblk0p6
8) Replace vendor/lge/p990/proprietary/lib/liblgeril.so with the one attached or edit it with a hex editor and change mmcblk0p3 with mmcblk0p5
9) Fix reboot-to-recovery by editing the file device/lge/star-common/prebuilt/setup-recovery and change it to this
Code:
#!/system/bin/sh
echo "boot-recovery" | dd of=/dev/block/mmcblk0p5 seek=6144 bs=1
10) Time for a brunch ! Compile cm10 as usual, then in out/target/product/p990 grab system.img and boot.img and copy them to your nvflash folder... that of course you know how to use and already have installed I used the ICS nvflash pack from Stefan and from Topogigi. Leave the defaults as they are, replace system.img and boot.img and flash
DO NOT FLASH THE INTERNAL SD CONTENTS OF THE ICS ROMS !!!
11) Fix the sdcard by enabling debug mode after the first boot, enter via adb and manually mount it with "mount -t ext3 /dev/block/mmcblk0p11 /storage/sdcard0". Then go in settings -> storage and format it from there.
Hope this is everything... if i forgot something shout
Update: The attached ics-partitions.cfg file for nvflash has the ext3 fs fix for the MSC partition... better safe than sorry
Attachments: http://forum.xda-developers.com/attachment.php?attachmentid=1577239&d=1355958301
http://forum.xda-developers.com/attachment.php?attachmentid=1577265&d=1355958826
Click to expand...
Click to collapse
Orginalpost: http://forum.xda-developers.com/showpost.php?p=35661482&postcount=100
Big thanks to all User and Devs where help him and the specially Thanks go to pengus77
Important: Use it at own risk, when you brick your phone... dont blame me
This is for CM10 based Builds: http://d-h.st/Nfe
This is for CM10.1 based Builds: http://d-h.st/5VO

You need to edit the cm10 kernel itself to make it bootable with the new partition.
Sent from my LG-P990 using xda app-developers app

I have no Linux to edit the kernel. And unfortunately I do not also the knowledge. I figured that you can get as basics to run it. I dealt with the feasibility

Need kernel dev to do this. This is the best way to prove if the layout partition is indeed has nothing to do with the call bug.
Sent from RC's Official CM10

Okay will get you kernel img tomorrow with proper ICS ramdisk.
You will need to put that kernel and modules in cm10 zip and also change updater script as necessary.
Sent from my Nexus 4

Finished my build. Waiting to nvflash my phone to new partition and then test. *fingers crossed*

Imperticus said:
Finished my build. Waiting to nvflash my phone to new partition and then test. *fingers crossed*
Click to expand...
Click to collapse
so if it works, u will give a link, so other ppl can try it too? :fingers-crossed:

Using CM10 with the old and the new bootloader?
There is no need to reinvent the wheel: just use wkpark's excellent patch on CM10 (kernel) source.
http://forum.xda-developers.com/showpost.php?p=33993473&postcount=636

not working for me, dont have time to try fix it. guess i'll just wait for harsh.

Here is cwm flashable new CM10 with modified kernel for NEW BOOTLOADER. It is untested (I am using ICS on old boot loader), so booting up is not guaranteed.
Those who dont know what they are doing, please stay away from this download.
http://d-h.st/auX
You will need NEW Bootloader, partition and recovery for new bootloader.

I am on ROM_OptiICS-v0.6_LGP990_CWM-v6_v28G-based_NVflash can i try this from CMW like full wipe + wipe cash then install from SD

komunistvb said:
I am on ROM_OptiICS-v0.6_LGP990_CWM-v6_v28G-based_NVflash can i try this from CMW like full wipe + wipe cash then install from SD
Click to expand...
Click to collapse
yes, but dont forget to backup first. This is highly experimental cm10.
Let me know how it goes.

thank u i will try it!

Harsh said:
Here is cwm flashable new CM10 with modified kernel for NEW BOOTLOADER. It is untested (I am using ICS on old boot loader), so booting up is not guaranteed.
Those who dont know what they are doing, please stay away from this download.
http://d-h.st/auX
You will need NEW Bootloader, partition and recovery for new bootloader.
Click to expand...
Click to collapse
I was having problem with the updater-script, it wasnt flashing properly. Guess i tried changing too much.

Imperticus said:
I was having problem with the updater-script, it wasnt flashing properly. Guess i tried changing too much.
Click to expand...
Click to collapse
Not to mess with updater script too much, just change system mmcblk0p1 to mmcblk0p12 and change for kernel from mmcblk0p5 to mmcblk0p6.
thats all i did in script.
and changed kernel with ramdisk for same. nothing more in system

Try to flash via CMW-based Recovery v6.0.1.5 and get this
(Status 7) Error

So, first test: I can Flash it when i remove the first line (assert(getprop("ro.product.device") == "p990" || getprop("ro.build.product") == "p990")
But dont boot yet. I dont see the Bootanimation,
I test it with a another combination
EDIT: @ Harsh, the Topogigi SP 2 Kernel are the best Basis i think, i can with this see the Bootanimation. Have a look in Topogigis Kernel and boot.img. With yours i see only the LG Logo

MetaIIica said:
So, first test: I can Flash it when i remove the first line (assert(getprop("ro.product.device") == "p990" || getprop("ro.build.product") == "p990")
But dont boot yet. I dont see the Bootanimation,
I test it with a another combination
EDIT: @ Harsh, the Topogigi SP 2 Kernel are the best Basis i think, i can with this see the Bootanimation. Have a look in Topogigis Kernel and boot.img. With yours i see only the LG Logo
Click to expand...
Click to collapse
His kernel boot.img have ramdisk from ICS stock. This one has modified CM10 ramdisk. Will check if change of ramdisk matters or not.

Harsh said:
Here is cwm flashable new CM10 with modified kernel for NEW BOOTLOADER. It is untested (I am using ICS on old boot loader), so booting up is not guaranteed.
Those who dont know what they are doing, please stay away from this download.
http://d-h.st/auX
You will need NEW Bootloader, partition and recovery for new bootloader.
Click to expand...
Click to collapse
Too much slow to download
Sent from my LG-P990 using xda app-developers app

Edit: see my next post

The CWM for Ouya project

Well, since i'm not aware of anyone else doing it, and it will be necessary for any real development to occur, I have decided to try porting Clockworkmod Recovery to the Ouya. I am downloading ubuntu right now and I'll start trying to build it from source against our current recovery tonight or tomorrow night depending on how long the setup and prerequisites take.
The reason I'm posting this now, is to solicit help. I've never built CWM before, but XDA has a really great tutorial I'm going to follow, but if anyone here has had experience in the past I'd love some help/tips, and other than that I would like a few brave souls to volunteer and try flashing it on their Ouya when/if I have a build that works on my own.
I'll update this thread with my progress, if I make any, and please let me know if any of you are willing to help in any way.
Update 1:
I have compiled a version of CWM recovery that theoretically should work, but I'm unable to flash it. I have installed flash_image onto the ouya and it works fine, but i normally would have used "flash_image recovery recovery.img" however there is no "recovery" partition on the ouya. This is what I get:
./flash_image recovery recovery.img
error scanning partitions: No such file or directory
Mount reveals the following info:
mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro,relatime,user_xatt
r,acl,barrier=1,data=ordered 0 0
/dev/block/platform/sdhci-tegra.3/by-name/CAC /cache ext4 rw,nosuid,nodev,noatim
e,errors=panic,user_xattr,acl,barrier=1,journal_async_commit,nodelalloc,data=wri
teback 0 0
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 rw,nosuid,nodev,noatime
,errors=panic,user_xattr,acl,barrier=1,journal_async_commit,nodelalloc,data=writ
eback 0 0
/dev/fuse /storage/sdcard0 fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1
023,default_permissions,allow_other 0 0
This is the script from the OTA update:
#!/system/bin/sh
if ! applypatch -c EMMC:/dev/block/platform/sdhci-tegra.3/by-name/SOS:5906432:f80238c4f4a53888b547e4463fb4751343f23412; then
log -t recovery "Installing new recovery image"
applypatch EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5277696:5d7013bf98f76199ea5b7d7d8baeb07fa3ad26ff EMMC:/dev/block/platform/sdhci-tegra.3/by-name/SOS f80238c4f4a53888b547e4463fb4751343f23412 5906432 5d7013bf98f76199ea5b7d7d8baeb07fa3ad26ff:/system/recovery-from-boot.p
else
log -t recovery "Recovery image already installed"
fi
but I can't make any sense of it. If anyone can help out i'd much appreciate it...

sonofskywalker3 said:
but I can't make any sense of it. If anyone can help out i'd much appreciate it...
Click to expand...
Click to collapse
This seems to be the magic lines in the update script:
if ! applypatch -c EMMC:/dev/block/platform/sdhci-tegra.3/by-name/SOS:5906432:f80238c4f4a53888b547e4463fb4751343f23412; then
log -t recovery "Installing new recovery image"
applypatch EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX:5277696:5d7013bf98f76199ea5b7d7d8baeb07fa3ad26ff EMMC:/dev/block/platform/sdhci-tegra.3/by-name/SOS f80238c4f4a53888b547e4463fb4751343f23412 5906432 5d7013bf98f76199ea5b7d7d8baeb07fa3ad26ff:/system/recovery-from-boot.p
Click to expand...
Click to collapse
I don't know much about the applypatch program. It might just be another script. Since it isn't being called with a "./", I'd imagine it is installed somewhere that the path mentions. Try looking for "applypatch" to see if it is a program or script. In a terminal running on the Ouya, try running "echo $PATH". Hopefully you get a list of directories containing program locations (e.g. /usr/bin/ ...etc). Applypatch might be in one of those directories.
UPDATE 1:
applypatch is a binary, not a script. It is located in /system/bin/
I tried running it without arguments on my Nexus 7 (to see if we would luck out with a nice "usage" message), but for some annoying reason I can't give it execute permissions, even as root. I'll look deeper into the scripts
UPDATE 2:
I need to verify this on my Ouya, but from the updater-script in the latest OTA, the kernel partition is /dev/block/platform/sdhci-tegra.3/by-name/LNX (I'm going out on a limb here boys, but I think LNX stands for Linux, aka, our kernel, lol).
UPDATE 3:
Seems like the recovery partition is /dev/block/platform/sdhci-tegra.3/by-name/SOS
I don't know much about the details of "applypatch", but the recovery script you posted above seems to first check to see if the recovery partition hashes to f80238c4f4a53888b547e4463fb4751343f23412 (the hash of the latest and greatest recovery). If it doesn't, then we flash the latest recovery, which from the looks of it consists of the kernel (in LNX) with a patch applied to it from recovery-from-boot.p (another mess of binary). In other words, it looks like they build a recovery from the existing kernel, as the name "recovery-from-boot" implies (the kernel is packaged in a file called boot.img).
Long story short, it looks like you can write to the block device /dev/block/platform/sdhci-tegra.3/by-name/SOS to write a new recovery. Aka, in a hacked version of the OTA script, include the line
package_extract_file("recovery.img", "/dev/block/platform/sdhci-tegra.3/by-name/SOS");
where recovery.img is the name of your new recovery. They did something very similar to the kernel (LNX). I'm pretty sure that the correct way to do something like this is to use "dd" after verifying the image is correct (by running a hash against the image). I'm not sure why the Ouya team is using package_extract_file() instead of dd. I'm not in front of my Ouya though, LNX and SOS could be folders rather than block devices (although /dev/block seems to imply otherwise).
You can remove most of the other lines in the script that install the actual OTA update files. If you need help, let me know. I can make a custom update-script for you.
WARNING!!!!!!!! The above is just my take on things from looking at the scripts for 20 minutes. This could total brick your device if your recovery isn't of the right format or is not correctly built. Don't say I didn't warn ya.
You might want to read off the contents of the SOS to compare in a hex editor to your recovery. We might find out some things that would prevent a brick.
Sent from my Nexus 7 using xda premium

Thank you for all your detailed information. I assumed that if my cwm recovery build failed I could just flash the boot.img from the ota and restore it, but it sounds like that might not be correct if the update is dependent on a hashed, preexisting recovery/kernel. I used the boot.img from the ota to build the recovery at http://builder.clockworkmod.com/ and it showed successful and gave me these four files:
https://dl.dropboxusercontent.com/u/7653846/Archive.zip
So to test, should I be able to flash_image /dev/block/platform/sdhci-tegra.3/by-name/SOS recovery.img?
my concern is that particular block doesn't show up on a mount command...

sonofskywalker3 said:
Thank you for all your detailed information. I assumed that if my cwm recovery build failed I could just flash the boot.img from the ota and restore it, but it sounds like that might not be correct if the update is dependent on a hashed, preexisting recovery/kernel. I used the boot.img from the ota to build the recovery at http://builder.clockworkmod.com/ and it showed successful and gave me these four files:
https://dl.dropboxusercontent.com/u/7653846/Archive.zip
So to test, should I be able to flash_image /dev/block/platform/sdhci-tegra.3/by-name/SOS recovery.img?
my concern is that particular block doesn't show up on a mount command...
Click to expand...
Click to collapse
I'm putting together an zip to flash in the stock recovery. This way we mimic what the stock updates do to flash over partitions.
I'm reading http://forums.ouya.tv/discussion/1380/recovery-mode right now in order to figure out how to get into the stock recovery.
One thing that I noticed is that I think your recovery is slightly larger than the stock one. I'm not sure how large SOS is, but I wouldn't want to flash over adjacent blocks (i.e. write out of bounds).

Makes sense. You must know something I don't if you can get it to flash in stock recovery... I tried simply adding files to the ota zip and flashing it and it failed.

sonofskywalker3 said:
Makes sense. You must know something I don't if you can get it to flash in stock recovery... I tried simply adding files to the ota zip and flashing it and it failed.
Click to expand...
Click to collapse
It probably doesn't work because the update.zip we're using is signed.
Just a thought, but an easier way to go, albeit dangerous, is to do the following. You need root access over adb to do this. Using dd is VERY dangerous. THIS MIGHT NOT WORK. We need to make sure that what we are writing to (/dev/block/platform/sdhci-tegra.3/by-name/SOS) is truly the block device containing the recovery partition or else this might brick the Ouya. In the past, I've seen recovery written to /dev/block/mmcblk0pX, where X is the recovery partition for the particular device. I'm not much of a tegra guy. I know more about Samsung's stuff.
1) place the recovery.img on your ouya (let's say in /sdcard/recovery.img)
2) open a terminal running on your Ouya (over adb would probably be best, e.g. "adb shell")
3) enter a root shell, type "su"
4) make a backup of your existing recovery partition with "dd if=/dev/block/mmcblk0p1 of=/sdcard/origRecovery.img"
5) write the new recovery to the recovery partition with "dd if=/sdcard/recovery.img of=/dev/block/mmcblk0p1"
6) perform the following from user mbm in the Ouya forums to get into recovery (thread http://forums.ouya.tv/discussion/1380/recovery-mode)
This is a hack, an unintended sequence of events that results in recovery mode; what you need to do is crash the startup using sysrq.
For this you'll need a usb keyboard with the sysrq key, this is usually the printscreen button if your keyboard isn't labeled. As the OUYA starts to boot, hold down the alt-sysrq keys and press i, wait a few seconds and then repeat. This key combination is kill-all-tasks; thanks to whoever left this enabled in the kernel. Each time you kill the tasks the init process will restart them, after about 5 or 6 times init will print a warning on the console that one of the processes marked critical has been restarted too many times -- this then triggers an automatic reboot into recovery mode.
Unfortunately it's not always obvious when the ouya is in recovery mode. You might get screen with the ouya logo and a large red exclamation mark, or the screen might be entirely black; usually I got a black screen. Press the home button on the keyboard to bring up the recovery menu; it's actually a toggle so feel free to press the home button repeatedly until you see the menu since the timing isn't otherwise obvious.
Click to expand...
Click to collapse
There are two big unknowns here:
1) We don't know for sure that the new recovery (CWM) will actually work
2) We don't know for sure that /dev/block/platform/sdhci-tegra.3/by-name/SOS is the correct place to be writing a recovery
I'll see what I can dig up regarding /dev/block/platform/sdhci-tegra.3/by-name/SOS
---------- Post added at 02:53 PM ---------- Previous post was at 02:30 PM ----------
/dev/block/platform/sdhci-tegra.3/by-name/SOS is a link to /dev/block/mmcblk0p1
So far, it appears that the layout is the following:
Kernel (boot.img) is mmcblk0p2
Recovery is mmcblk0p1
System is mmcblk0p3
Sent from my SCH-I535 using xda premium
---------- Post added at 02:56 PM ---------- Previous post was at 02:53 PM ----------
I would imagine that if the recovery partition really is SOS, then the above steps would work if you could run them as root.
Sent from my SCH-I535 using xda premium

Some definite info:
SOS is recovery
OUYA firmware updates patches the boot partition on the fly (binary patching) - silly and error prone, but *shrug*. Don't need apply patch at all. dd is fine
It's much safer to use 'fastboot boot recovery.img' while in fastboot mode. This allows loading recovery or boot.img's into ram and execute them from there. Once that works 100%, you can flash it to SOS.
As most people already know, it's not possible to force the device into recovery. It has to be done with something like 'adb reboot recovery'.

mybook4 said:
I'm putting together an zip to flash in the stock recovery. This way we mimic what the stock updates do to flash over partitions.
I'm reading http://forums.ouya.tv/discussion/1380/recovery-mode right now in order to figure out how to get into the stock recovery.
One thing that I noticed is that I think your recovery is slightly larger than the stock one. I'm not sure how large SOS is, but I wouldn't want to flash over adjacent blocks (i.e. write out of bounds).
Click to expand...
Click to collapse
It's 8MB. If you dd to the block device (e.g. mmcblk0p1), you can't write out of bounds. The linux kernel knows the size and refuses it.

rayman said:
Some definite info:
SOS is recovery
OUYA firmware updates patches the boot partition on the fly (binary patching) - silly and error prone, but *shrug*. Don't need apply patch at all. dd is fine
It's much safer to use 'fastboot boot recovery.img' while in fastboot mode. This allows loading recovery or boot.img's into ram and execute them from there. Once that works 100%, you can flash it to SOS.
As most people already know, it's not possible to force the device into recovery. It has to be done with something like 'adb reboot recovery'.
Click to expand...
Click to collapse
I did the following with skywalker's recovery.
1) Attached a usb keyboard to the Ouya's full size usb port
2) Attached my computer to the Ouya's micr usb port
3) Ran "adb reboot bootloader" (the Ouya rebooted to a blank screen)
4) Waited 30 seconds and ran "fastboot boot recovery.img" (skywalker's recovery file)
The Ouya rebooted into CWM Recovery v6.0.3.2!
Error messages were encountered on the recovery screen (image attached)
5) Navigated around CWM with the arrow keys and the enter key
6) Rebooted with "reboot system now". Ouya booted right up.
When we flash the recovery to mmcblk0p1, we should rename /system/etc/install-recovery.sh (and maybe /system/recovery-from-boot.p) to prevent the recovery partition from being overwritten.
Looks like we need to adjust the recovery so it properly mounts the partitions. Hopefully after that we are good to go.

Wow, that's awesome progress! So I'll try the same steps when I get home tonight and then try building another recovery with proper mount points.

sonofskywalker3 said:
Wow, that's awesome progress! So I'll try the same steps when I get home tonight and then try building another recovery with proper mount points.
Click to expand...
Click to collapse
I think it should be a matter of placing the proper partitions in the fstab prior to creating the recovery image. From the error messages it looks like /cache and /data are the culprits.
If you get a chance to, please post the fstab you use so we can double check everything (want to avoid the potential for bricks).
Sent from my SCH-I535 using xda premium

I did the build without a custom fstab first to see if it would work. I'll make one tonight, or if anyone here has done it before feel free to make sure it's done right, this will be my first try at it.
Update:
Started making the fstab and got rid of the errors on my second build, seems it still can't mount some. making progress though.
Update2:
I have compiled a new recovery using the following recovery.fstab:
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA
/sdcard fuse /dev/fuse
this is based on information gathered from the mount command in an adb shell. it no longer gives the long string of errors, or complains that it can't mount any partitions except i get the following errors now:
can't mount /cache/recovery/command
can't mount /cache/recovery/last_log
can't open /cache/recovery/last_log
and a few others. not sure how to proceed at this point. I'm searching Google, but has anyone run into this before?

sonofskywalker3 said:
I did the build without a custom fstab first to see if it would work. I'll make one tonight, or if anyone here has done it before feel free to make sure it's done right, this will be my first try at it.
Update:
Started making the fstab and got rid of the errors on my second build, seems it still can't mount some. making progress though.
Update2:
I have compiled a new recovery using the following recovery.fstab:
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA
/sdcard fuse /dev/fuse
this is based on information gathered from the mount command in an adb shell. it no longer gives the long string of errors, or complains that it can't mount any partitions except i get the following errors now:
can't mount /cache/recovery/command
can't mount /cache/recovery/last_log
can't open /cache/recovery/last_log
and a few others. not sure how to proceed at this point. I'm searching Google, but has anyone run into this before?
Click to expand...
Click to collapse
I'm still new at making a recovery.fstab, but I noticed the following:
From running "ls -l /dev/block/platform/sdhci-tegra.3/by-name/"
lrwxrwxrwx root root 2013-05-25 02:23 APP -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2013-05-25 02:23 CAC -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2013-05-25 02:23 LNX -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2013-05-25 02:23 MDA -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2013-05-25 02:23 MSC -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2013-05-25 02:23 SOS -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2013-05-25 02:23 UDA -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2013-05-25 02:23 UPP -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2013-05-25 02:23 USP -> /dev/block/mmcblk0p7
Click to expand...
Click to collapse
Since the APP, CAC, LNX files are links to mmcblk0pX devices, maybe we should be using the mmcblk0pX names?
We should look at more examples to see what the recovery.fstab for other devices looks like. From what I've seen of other devices, mmcblk0pX devices are listed in recovery.fstab.
P.S. So far, I think we are fairly certain that
APP is the system partition
CAC is the cache partition
LNX is kernel boot.img
SOS is the recovery partition
I'm not sure what the rest are (data, etc). Is there a definitive list somewhere?

Here's what I was able to find based on your suggestion, it's the recovery.fstab from the nexus 7:
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA length=-32768
/misc emmc /dev/block/platform/sdhci-tegra.3/by-name/MSC
/boot emmc /dev/block/platform/sdhci-tegra.3/by-name/LNX
/recovery emmc /dev/block/platform/sdhci-tegra.3/by-name/SOS
/staging emmc /dev/block/platform/sdhci-tegra.3/by-name/USP
Obviously this isn't exactly right, but it's a start until we can find more about the mounts.
I tried making the recovery.fstab using the mmcblk numbers but that made no difference... Cache always mounts empty. I'm going to try one more thing, then I'll post my final results and go to bed.
Update:
Well still no love, and no noticeable progress between recovery 2 and 7, but I feel like we're chipping away in the right direction. I'll seek some help from some more experienced recovery people tomorrow.

sonofskywalker3 said:
Here's what I was able to find based on your suggestion, it's the recovery.fstab from the nexus 7:
/systemext4/dev/block/platform/sdhci-tegra.3/by-name/APP
/cacheext4/dev/block/platform/sdhci-tegra.3/by-name/CAC
/dataext4/dev/block/platform/sdhci-tegra.3/by-name/UDAlength=-32768
/misc emmc /dev/block/platform/sdhci-tegra.3/by-name/MSC
/bootemmc/dev/block/platform/sdhci-tegra.3/by-name/LNX
/recoveryemmc/dev/block/platform/sdhci-tegra.3/by-name/SOS
/staging emmc /dev/block/platform/sdhci-tegra.3/by-name/USP
Obviously this isn't exactly right, but it's a start until we can find more about the mounts.
I tried making the recovery.fstab using the mmcblk numbers but that made no difference... Cache always mounts empty. I'm going to try one more thing, then I'll post my final results and go to bed.
Click to expand...
Click to collapse
Good stuff.
Not sure how we are going to get the field length= . I noticed the same field being used in the US Galaxy S III recovery https://raw.github.com/CyanogenMod/android_device_samsung_d2-common/cm-10.1/recovery.fstab
length= field is probably not needed, as the stock recovery doesn't list it.
Sent from my SCH-I535 using xda premium

Here's the recovery.fstab from my Ouya's recovery partition.
# mount point fstype device
/recovery emmc /dev/block/platform/sdhci-tegra.3/by-name/SOS
/boot emmc /dev/block/platform/sdhci-tegra.3/by-name/LNX
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/misc emmc /dev/block/platform/sdhci-tegra.3/by-name/MSC
/staging emmc /dev/block/platform/sdhci-tegra.3/by-name/USP
/metadata emmc /dev/block/platform/sdhci-tegra.3/by-name/MDA
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA
/sdcard vfat /dev/block/platform/sdhci-tegra.0/by-num/p1
Click to expand...
Click to collapse
I tried doing CWM build with this recovery.fstab. /system, /data, and /cache all mounted.
Couldn't mount /sdcard automatically (trying to choose zip from sdcard) or manually (in mounts and storage, mount /sdcard).
I tweaked the recovery.fstab to the following:
/recovery emmc /dev/block/platform/sdhci-tegra.3/by-name/SOS
/boot emmc /dev/block/platform/sdhci-tegra.3/by-name/LNX
/system ext4 /dev/block/platform/sdhci-tegra.3/by-name/APP
/cache ext4 /dev/block/platform/sdhci-tegra.3/by-name/CAC
/misc emmc /dev/block/platform/sdhci-tegra.3/by-name/MSC
/staging emmc /dev/block/platform/sdhci-tegra.3/by-name/USP
/metadata emmc /dev/block/platform/sdhci-tegra.3/by-name/MDA
/data ext4 /dev/block/platform/sdhci-tegra.3/by-name/UDA
/sdcard datamedia /dev/null
Click to expand...
Click to collapse
This one mounted /sdcard correctly. I can "choose a zip from sdcard". I didn't actually choose a zip yet. I didn't format any of the partitions. I suppose we could try making a quick cwm zip to write something to the sdcard to test it out.
I've attached the stock Ouya recovery.img (from SOS partition). THIS IS NOT A CWM FLASHABLE ZIP, it only contains a zipped up version of the stock recovery.img. The md5 hash of the unzipped recovery.img is a6c1a6962984e9080ed8821628c4cc3f.
I've attached the CWM recovery.img that worked for me. THIS IS NOT A CWM FLASHABLE ZIP, it only contains a zipped up version of a newly built CWM recovery.img. The md5 hash of the unzipped recovery.img is c6b37906f280b16cd200503c3cde6dfb.

well, when I build using your suggested recovery.fstab i'm still getting the same error about the cache, but i booted the cwm you built and saw what you meant. can you post your actual recovery.fstab file so I can try to build with it? where did you get the boot.img you are using?
Update!
It worked!! I booted to your attached cwm and I'm running a nandroid backup right now. I'll try a restore next. In the meantime I'm putting together a Playmusic.zip flashable zip with the files necessary to get play music up and running and I'll try flashing it. Awesome work tracking down those partitions!

sonofskywalker3 said:
well, when I build using your suggested recovery.fstab i'm still getting the same error about the cache, but i booted the cwm you built and saw what you meant. can you post your actual recovery.fstab file so I can try to build with it? where did you get the boot.img you are using?
Click to expand...
Click to collapse
I edited the comment right above yours.
Recovery Builder wants the stock recovery.img, so I used adb to copy my Ouya's recovery partition to the sdcard, then I used adb pull to copy the recovery partition to my computer.
1) adb shell
2) su
3) cd /dev/block/platform/sdhci-tegra.3/by-name
4) dd if=SOS of=/sdcard/stockRecovery.img
5) exit
6) adb pull /sdcard/stockRecovery.img .
I used the recovery.fstab attached to this post. I obtained the stock Ouya recovery.fstab by doing the following:
I used split_bootimg.pl to split up the recovery.img into kernel and ramdisk (see Alternate Method in http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images). I used gzip to unzip the ramdisk and saw the stock recovery.fstab in /etc.
Here's what I did step by step:
1) split_bootimg.pl stockRecovery.img
2) mkdir ramdisk
3) cd ramdisk
4) gzip -dc ../stockRecovery.img-ramdisk.gz | cpio -i
in the ramdisk directory is etc/recovery.fstab
I then copied this file and edited the last line (/sdcard stuff). I used the new recovery.fstab with the Recovery Builder.

sonofskywalker3 said:
It worked!! I booted to your attached cwm and I'm running a nandroid backup right now. I'll try a restore next. In the meantime I'm putting together a Playmusic.zip flashable zip with the files necessary to get play music up and running and I'll try flashing it. Awesome work tracking down those partitions!
Click to expand...
Click to collapse
Awesome! Let us know how the backup/restore and zip flashing goes.
Once we verify that this CWM works correctly, people should be able write the new recovery by doing the following (NOTE this wasn't tested yet. I need to test it out first):
1) adb reboot bootloader
2) wait 30 seconds (blank screen is normal)
3) fastboot flash recovery recovery.img
4) fastboot reboot recovery (need a usb keyboard to navigate CWM)
5) flash a CWM zip to prevent stock recovery overwrite (we need to make this. The zip file should mount /system, rename recovery-from-boot.p to recovery-from-boot.bak, and unmount /system)
6) profit
Most of this could potentially be automated into a root/install CWM script.

Backup worked fine, flash worked and I'm booting now to make sure it put the files where it was supposed to and see if they work. Then i'll reboot and restore and make sure those files go away.One thing to note is that when i choose reboot system now it asked me to disable recovery flash,so I took the plunge and said yes, we'll see if it goes back to stock or not...
Update:
The .zip I built said it flashed correctly (unless i'm reading wrong the parts i could see with the overscan problems i'm having) but the files did not go to /system/app. I have attached the .zip file to see if I did something wrong with it, I just grabbed a sample from online and changed the files, haven't checked updater-script yet. I am restoring now, will post update on if that works.
It rebooted to stock recovery, as I expected, so still haven't flashed it just yet.
Well my oversensitive keyboard just hit enter twice so I'm actually backing up again, but I have to leave and take my daughter to a muesuem now, so I won't be able to continue until later. Good luck, i'll be keeping up with this thread on my phone.
Edit: removed non working zip

Device Essential Material *** Firmware, Source Code, Root etc.***

This thread will list and link to all core device essential stuff.
PM me if there is new stuff please​
STOCK ASUS FIRMWARE
WW_epaduser_10_26_1_18_UpdateLauncher.zip: HERE
US_epaduser_10_26_1_18_UpdateLauncher.zip: HERE
CN_epaduser_10_26_1_18_UpdateLauncher.zip: HERE
TW_epaduser_10_26_1_18_UpdateLauncher.zip: HERE
Seperate Sd update for WW versions to recover from wrong released OTA, when unzipped place it on MicroSdcard and reboot:
WW_10_26_1_18_SDupdate.zip: HERE
US_epaduser_10_26_1_7_UpdateLauncher.zip: HERE
TW_epaduser_10_26_1_7_UpdateLauncher.zip: HERE
WW_epaduser_10_26_1_7_UpdateLauncher.zip: HERE
CN_epaduser_10_14_1_47_UpdateLauncher.zip: HERE
JP_epaduser_10_14_1_47_UpdateLauncher.zip: HERE
US_epaduser_10_14_1_47_UpdateLauncher.zip: HERE
WW_epaduser_10_14_1_47_UpdateLauncher.zip: HERE
WW_epaduse_10_14_1_45_UpdateLauncher.zip: HERE
TW_epaduse_10_14_1_45_UpdateLauncher.zip: HERE
US_epaduse_10_14_1_45_UpdateLauncher.zip: HERE
CN_epaduse_10_14_1_45_UpdateLauncher.zip: HERE
CN_epaduser_10_14_1_42_UpdateLauncher.zip: HERE
How to flash:
Step 1: Download and unzip the zipfile of your choice.
Step 2: Copy the new Zipfile and paste it in root directory of your internal SdCard, then reboot the device and the update will automatically start.
ASUS SOURCE CODE
kernel_10_14_1_42.rar: HERE
kernel_10_14_1_45.rar: HERE
kernel_10_14_1_47.rar: HERE
kernel_10_26_1_7.rar: HERE
kernel_10_26_1_18.rar: HERE
UNLOCK YOUR DEVICE
0820-0954_SIGNED_UnLock_for_TF701_repart.apk: HERE
How to unlock:
- Download the Asus unlock app
- Install and run the app. This will require a valid google account (if you use one time passwords, you'll need to generate one for this purpose) and internet access.
- When booting with [vol-] + [power] pressed, the transformer will show the message "The device is unlocked"
ROOT TOOLS
Read here: http://forum.xda-developers.com/showthread.php?t=2516215
CUSTOM RECOVERY
Altered CWM Recovery V6.0.3.7. for 4.2.2.*: HERE
ATTENTION: you must have an unlocked bootloader
How to flash this:
- reboot device into fastboot mode:
- adb reboot bootloader
- now flash the recovery using : fastboot flash recovery CWMrecovery4.2.2.img [where CWMrecovery4.2.2.img is the name of the file image you downloaded]
There is at the moment no CWM-Recovery or TWRP-Recovery for 4.3. version yet!!!
* With thanks to Drgravy for his work on that.
CUSTOM ROM'S
None available yet.
Will be released by Sbdags when there is a custom recovery for 4.3. available.
THEMES
Non available yet
BOOTANIMATIONS
Non available yet
OTHER MOD'S
None available yet
PARTITION INFORMATION**
Code:
name device mountpoint fs description
/dev/block/platform/sdhci-tegra.3/ADF /dev/block/mmcblk0p7 /ADF ext4 ?
/dev/block/platform/sdhci-tegra.3/APD /dev/block/mmcblk0p6 /APD ext4 ASUS Product Demo
/dev/block/platform/sdhci-tegra.3/APP /dev/block/mmcblk0p4 /system ext4 Android OS
/dev/block/platform/sdhci-tegra.3/CAC /dev/block/mmcblk0p5 /cache ext4 recovery logs
/dev/block/platform/sdhci-tegra.3/CRA /dev/block/mmcblk0p11 ?
/dev/block/platform/sdhci-tegra.3/DTB /dev/block/mmcblk0p2 ?
/dev/block/platform/sdhci-tegra.3/EKS /dev/block/mmcblk0p13 NVEKSP
/dev/block/platform/sdhci-tegra.3/LNX /dev/block/mmcblk0p3 Linux kernel (8388608 b)
/dev/block/platform/sdhci-tegra.3/MDA /dev/block/mmcblk0p12 ?
/dev/block/platform/sdhci-tegra.3/MSC /dev/block/mmcblk0p8 empty (misc, bootloader etc.)
/dev/block/platform/sdhci-tegra.3/PER /dev/block/mmcblk0p10 /persist ext4 config/calibration data
/dev/block/platform/sdhci-tegra.3/SOS /dev/block/mmcblk0p1 Recovery kernel (8388608 b)
/dev/block/platform/sdhci-tegra.3/UDA /dev/block/mmcblk0p14 /data ext4 Android user data
/dev/block/platform/sdhci-tegra.3/USP /dev/block/mmcblk0p9 Staging (blob)
RECOVERY.FSTAB**
Code:
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro wait
/dev/block/platform/sdhci-tegra.3/by-name/CAC /cache ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait,encryptable=/dev/block/platform/sdhci-tegra.3/by-name/MDA
/dev/block/platform/sdhci-tegra.3/by-name/MSC /misc emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/LNX /boot emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/SOS /recovery emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/USP /staging emmc defaults defaults
/devices/platform/sdhci-tegra.2/mmc_host/mmc1 /storage/sdcard1 vfat default voldmanaged=sdcard:auto
/devices/platform/tegra-ehci.0 /mnt/usbdrive vfat default voldmanaged=usbdrive:auto
BLOB**
Code:
name size description status
10.14.1.47: [ATTACH]2435244[/ATTACH]
blob.BCT 8,192 Bytes Boot Config Table (original) [ATTACH]2435246[/ATTACH]
blob.BC1 8,192 Bytes ? (original) [ATTACH]2435245[/ATTACH]
blob.EBT 1,396,736 Bytes Bootloader (original) [ATTACH]2435247[/ATTACH]
blob.PT 2,202 Bytes Partition Table (original) [ATTACH]2435248[/ATTACH]
10.26.1.7: [ATTACH]2435238[/ATTACH]
blob.BCT 8,192 Bytes Boot Config Table (unchanged) [ATTACH]2435241[/ATTACH]
blob.BC1 8,192 Bytes ? (changed) [ATTACH]2435240[/ATTACH]
blob.EBT 1,421,312 Bytes Bootloader (changed) [ATTACH]2435242[/ATTACH]
**= Thanks to Ipdunwell for sharing this info
HOW TO UNBRICK YOUR DEVICE
Read here: http://forum.xda-developers.com/showpost.php?p=47933481&postcount=1
ATTENTION​
YOUR WARRANTY COULD BE VOID DUE TO ROOTING AND UNLOCKING YOUR DEVICE (depending of which country you reside)
I am NOT responsible for bricked devices, dead SD cards or dead docks.
Please do some research if you have any concerns about the files here BEFORE flashing anything!
When you have no clue what we are talking about here you better leave your hands off it!!
YOU are choosing yourself freely to use these file(s) all by yourself!!!​

Odd that you just started this thread and it's outdated ;P
Updated Recovery for 4.3 with working "external" SD card, found here
http://forum.xda-developers.com/showthread.php?t=2621051
Custom Rom's
Cromi-x
http://forum.xda-developers.com/showthread.php?t=2608129
CM11 -Preview (Unofficial)
http://forum.xda-developers.com/showthread.php?t=2621028

Sorry folks. Thread closed as it already exists in the General Forum.
MD