[RECOVERY][UNOFFICIAL] CWM Recovery for Nvidia Shield Tablet

Do you think this tablet needs recovery and custom ROMs?

  • Yes

    Votes: 19 90.5%
  • No

    Votes: 2 9.5%

  • Total voters
    21
  • Poll closed .
Search This thread

Unjustified Dev

Recognized Developer
Oct 21, 2012
7,181
13,078
24
Memphis , TN
Couldn't decide if it would be worth starting an entirely separate thread, but I fixed the framebuffer so that it's oriented correctly. I thought about creating a merge request, but I was using NVIDIA's Tegra device tree, which is...really different.

In any case, here's my device tree. The bulk of the fix is in common/recovery/graphics.c, in the gr_flip() method. In the default graphics.c file, this method basically just does a memcpy() from memory to the framebuffer. The modified version is this:

Code:
void gr_flip(void)
{
        GGLContext *gl = gr_context;

        /* swap front and back buffers */
        if (double_buffering)
            gr_active_fb = (gr_active_fb + 1) & 1;

        int buffer = 0;
        int fbsize = fi.line_length * vi.yres;

        // Copy the in-memory buffer into the buffer we're about to make
        // active, but reverse the order of the pixels.
        for (buffer = 0; buffer < fbsize; buffer += 4)
        {
            const char *src = (char *)gr_mem_surface.data;
            char *dst = (char *)gr_framebuffer[gr_active_fb].data;

            // Since we're reversing the buffer data, we need to flip the order
            // of the subpixel values, too. Otherwise they'll be backwards.
            dst[(fbsize-(buffer+4))] = src[buffer-PIXEL_OFFSET];
            dst[(fbsize-(buffer+3))] = src[buffer+1-PIXEL_OFFSET];
            dst[(fbsize-(buffer+2))] = src[buffer+2-PIXEL_OFFSET];
            dst[(fbsize-(buffer+1))] = src[buffer+3-PIXEL_OFFSET];
        }

        /* inform the display driver */
        set_active_framebuffer(gr_active_fb);
}

There are a few other smallish adjustments that I had to make in order to get everything lined up correctly. That offset is because without it I was getting some weird padding on the right side of the screen, for example. Anyway, I've got it running on my LTE Shield and haven't had any issues. Did a backup, performed a partial restore, flashed SuperSu, etc.

If anyone wants to try the recovery, I've attached a zipped copy of the image. This is NOT a zip that you can flash from your current recovery, I just zipped it because the raw image exceeds XDA's file upload limit apparently. Unzip the image, then flash it or boot it via fastboot or Flashify or whatnot, just like any other recovery image. MD5 for the image (not the zip) should be 7959f08d9266b60da46f44ab4333c92a. I make no promises, but as I said, it's working fine on my Shield.

Nice! I will implement this when nvidia finally releases the lollipop tree. They are taking an extended amount of time I may go ahead and just bring up the device without them.
 
  • Like
Reactions: ciribaski

eldarerathis

Senior Member
Jun 21, 2010
159
316
Nice! I will implement this when nvidia finally releases the lollipop tree. They are taking an extended amount of time I may go ahead and just bring up the device without them.

Yeah, I was waiting for their Lollipop source to land, too, but got impatient. Since I only wanted to build the recovery I decided that using the KK device tree/kernel would suffice for now, and would be quicker than putting together a device tree from scratch.
 
  • Like
Reactions: ciribaski

Unjustified Dev

Recognized Developer
Oct 21, 2012
7,181
13,078
24
Memphis , TN
Yeah, I was waiting for their Lollipop source to land, too, but got impatient. Since I only wanted to build the recovery I decided that using the KK device tree/kernel would suffice for now, and would be quicker than putting together a device tree from scratch.

Well there are trees available already
https://github.com/TeamRegular/android_device_nvidia_wx_na_wf
https://github.com/TeamRegular/android_device_nvidia_shieldtablet
https://github.com/TeamRegular/android_kernel_nvidia_shieldtablet
https://github.com/TeamRegular/proprietary_vendor_nvidia

Haven't you seen the ROMs already?

I plan on redoing those in a week or so hopefully lollipop source is out by then. Only problem roms have is touch screen issues I have not finished the update to latest code and gps does not work that issues persist on their aosp builds as well. I don't have the device but it seems you have the device and skills. :good: make some people happy
 
  • Like
Reactions: ciribaski

eldarerathis

Senior Member
Jun 21, 2010
159
316
Well there are trees available already
https://github.com/TeamRegular/android_device_nvidia_wx_na_wf
https://github.com/TeamRegular/android_device_nvidia_shieldtablet
https://github.com/TeamRegular/android_kernel_nvidia_shieldtablet
https://github.com/TeamRegular/proprietary_vendor_nvidia

Haven't you seen the ROMs already?

I plan on redoing those in a week or so hopefully lollipop source is out by then. Only problem roms have is touch screen issues I have not finished the update to latest code and gps does not work that issues persist on their aosp builds as well. I don't have the device but it seems you have the device and skills. :good: make some people happy

I thought it might be easier to debug the framebuffer weirdness if I was starting with the vanilla tree as a base, to make sure there was nothing going on in the other trees that was causing it. In reality, I don't think it would have mattered because the issue was lower than that, but once I started I didn't feel like moving everything into another tree.

I was also considering trying an AOSP Lollipop build, but I base my builds on AOSP, not CM, so I wanted to try to stick closer to NVIDIA's "AOSP" tree. If I have some time this weekend I might try making the same framebuffer changes in a fork of the TeamRegular tree, though, and then submit a proper merge request, just to make things easier.

I had really awful battery life when I did an AOSP KK build, though, so I'm not sure if I'll spend much time on Lollipop. Plus I can't decide if I want to keep the NVIDIA apps or not.
 
  • Like
Reactions: ciribaski
Yeah, I was waiting for their Lollipop source to land, too, but got impatient. Since I only wanted to build the recovery I decided that using the KK device tree/kernel would suffice for now, and would be quicker than putting together a device tree from scratch.

Honestly, there haven't been any changes to the part of the kernel that is relevant to a recovery since Jellybean as far as the Nvidia source goes. Rebasing for the newer kernel for a recovery only would be a waste of time.
 

Unjustified Dev

Recognized Developer
Oct 21, 2012
7,181
13,078
24
Memphis , TN
I thought it might be easier to debug the framebuffer weirdness if I was starting with the vanilla tree as a base, to make sure there was nothing going on in the other trees that was causing it. In reality, I don't think it would have mattered because the issue was lower than that, but once I started I didn't feel like moving everything into another tree.

I was also considering trying an AOSP Lollipop build, but I base my builds on AOSP, not CM, so I wanted to try to stick closer to NVIDIA's "AOSP" tree. If I have some time this weekend I might try making the same framebuffer changes in a fork of the TeamRegular tree, though, and then submit a proper merge request, just to make things easier.

I had really awful battery life when I did an AOSP KK build, though, so I'm not sure if I'll spend much time on Lollipop. Plus I can't decide if I want to keep the NVIDIA apps or not.

I actually used the aosp tree I just merged it all into one and took some stuff like sensors etc and use them as prebuilts. Other than that my tree is identical to Nvidia with cm support . You should be able to do a pure aosp lp build with minor patches from cm if any needed at all and of course set up the tree to use aosp configuration.
I only needed two which I pushed to cm from nvidia. I really didn't want to change the wifi configurations since the tree is close to aosp as possible I didn't want many changes.
http://review.cyanogenmod.org/71802
http://review.cyanogenmod.org/71804
 
  • Like
Reactions: ciribaski

jce2005

Senior Member
Jul 13, 2009
174
27
Hi eldarerathis,

flashed your "recovery.img" with Flashify and here are the results :

1. Flashed without any troubles on Shield Tablet 4G/LTE ( Rooted with Lollipop )
2. Orientation is correct
3. Backup to sdcard ( internal ) partially works......
BACKED UP : boot image / recovery image / system / data / cache, Generated MD5 checksum
NOT BACKED UP : applications ( ERROR : No .android_secure found. Skipping backup of applications on external storage)
4. Backup to /storage/sdcard1 failed ( ERROR : E: Unable to state backup path )

Any ideas or possibilities to get this fixed ?

Thanks, Great job from you and Unjustified Dev

JCE
 

eldarerathis

Senior Member
Jun 21, 2010
159
316
Hi eldarerathis,

flashed your "recovery.img" with Flashify and here are the results :

1. Flashed without any troubles on Shield Tablet 4G/LTE ( Rooted with Lollipop )
2. Orientation is correct
3. Backup to sdcard ( internal ) partially works......
BACKED UP : boot image / recovery image / system / data / cache, Generated MD5 checksum
NOT BACKED UP : applications ( ERROR : No .android_secure found. Skipping backup of applications on external storage)
4. Backup to /storage/sdcard1 failed ( ERROR : E: Unable to state backup path )

Any ideas or possibilities to get this fixed ?

Thanks, Great job from you and Unjustified Dev

JCE

Do you actually have apps installed on your SD card? The message isn't saying that it can't back up your apps, it's saying that it doesn't see any apps installed on your SD card. Anything on internal memory is backed up with the /data partition.

Dunno about the second message. Haven't seen it myself.
 

jce2005

Senior Member
Jul 13, 2009
174
27
Do you actually have apps installed on your SD card? The message isn't saying that it can't back up your apps, it's saying that it doesn't see any apps installed on your SD card. Anything on internal memory is backed up with the /data partition.

Dunno about the second message. Haven't seen it myself.
Hi,

Thanks for responding... Well, I moved several apps to the sdcard1.... I am a bit confused how Kitkat and lollipop handling a Microsd card... But for sure, the cwm backup to sdcard1 doesn't work in Kitkat or in lollipop....
 

Keithn

Senior Member
Feb 24, 2011
859
242
Google Pixel 6 Pro
Hi,

Thanks for responding... Well, I moved several apps to the sdcard1.... I am a bit confused how Kitkat and lollipop handling a Microsd card... But for sure, the cwm backup to sdcard1 doesn't work in Kitkat or in lollipop....

The recovery issue isn't the same as while booted. Starting with KitKat apps are only allowed to access specific folders on the SD. You can disable that easily with the sdfix app. Recovery was having issues with mounting the SD properly if I remember correctly.

Sent from my One M8
 

jce2005

Senior Member
Jul 13, 2009
174
27
Hi Keithn,

thanks for the reply. Well, I do know of and use the "NextApp SDFix" app. Did so in KitKat as well as in Lollipop ! However, the CWM Recovery works basically before the OS is booted, so it seems to me, that somewhere in CWM the path to sdcard is not properly working ( or as you stated it can't mount the sdcard )........ I am a pretty handy guy when it comes to PC's but not technically inclinded on Android, but it seems ( and I say seems !!! ) to me, that would be a easy fix since it must be the CWM and not the Android OS what causes the problem.

But heyyyyyy, maybe it's more difficult than my understanding. I never had any trouble by all my phones using CWM to mount or access the external sdcard for backup purposes.... So I am uncertain and don't understand why this ( to me ) small issue can't be addressed and fixed.

Unjustified Dev could probably answer why this can't b e fixed easily, otherwise I am sure he would have fixed it by now already.

Maybe someone could give me step-by-step directions on how I could do and ADB ( Nandroid ???? ) Backup on My Shield LTE Tablet until the CWM backup to sdcard works. I am sooooooo not familiar with the ADB commands and how to do a full backup/restore with ADB !!

Thanks in advance,

JCE
 
The recovery issue isn't the same as while booted. Starting with KitKat apps are only allowed to access specific folders on the SD. You can disable that easily with the sdfix app. Recovery was having issues with mounting the SD properly if I remember correctly.

Sent from my One M8


It's a square peg round hole mess with recovery wanting sdcard1 to fit a set design that no system seems to follow anymore.

Btw @eldarerathis and @Unjustified Dev, I believe you were waiting on http://nv-tegra.nvidia.com/gitweb/?...a=blob_plain;f=README;hb=rel-st8-l-r1-partner which hasn't been updated on the official Nvidia development site yet but is available if you happen to dig through their source for whatever reason ;)
 
Last edited:

Keithn

Senior Member
Feb 24, 2011
859
242
Google Pixel 6 Pro
It's a square peg round hole mess with recovery wanting sdcard1 to fit a set design that no system seems to follow anymore.

Btw @eldarerathis and @Unjustified Dev, I believe you were waiting on http://nv-tegra.nvidia.com/gitweb/?...a=blob_plain;f=README;hb=rel-st8-l-r1-partner which hasn't been updated on the official Nvidia development site yet but is available if you happen to dig through their source for whatever reason ;)

Tried digging before and didn'y see that, did it pop up in the last few days?

I'll try a quick build of the source and see if the kernel will actually support GPS or resolve any other issues this time. I really doubt it suddenly will work, but it's worth a try.

Sent from my One M8

---------- Post added at 01:12 PM ---------- Previous post was at 12:41 PM ----------

Hi eldarerathis,

flashed your "recovery.img" with Flashify and here are the results :

1. Flashed without any troubles on Shield Tablet 4G/LTE ( Rooted with Lollipop )
2. Orientation is correct
3. Backup to sdcard ( internal ) partially works......
BACKED UP : boot image / recovery image / system / data / cache, Generated MD5 checksum
NOT BACKED UP : applications ( ERROR : No .android_secure found. Skipping backup of applications on external storage)
4. Backup to /storage/sdcard1 failed ( ERROR : E: Unable to state backup path )

Any ideas or possibilities to get this fixed ?

Thanks, Great job from you and Unjustified Dev

JCE
I was just playing around with mine and backing up to sd1 seems to work on mine. What are you using for an sd card? model, size, format etc? I was playing with formats on mine so I can't remember if it's FAT32 or EXFAT, I will check. I can Backup and restore on sdcard1 just fine.
Mine is a 32GB Sandisk Extreme Plus formatted in FAT32. I
 
Last edited:
  • Like
Reactions: Unjustified Dev
Tried digging before and didn'y see that, did it pop up in the last few days?

I'll try a quick build of the source and see if the kernel will actually support GPS or resolve any other issues this time. I really doubt it suddenly will work, but it's worth a try.

Sent from my One M8

---------- Post added at 01:12 PM ---------- Previous post was at 12:41 PM ----------


I was just playing around with mine and backing up to sd1 seems to work on mine. What are you using for an sd card? model, size, format etc? I was playing with formats on mine so I can't remember if it's FAT32 or EXFAT, I will check. I can Backup and restore on sdcard1 just fine.
Mine is a 32GB Sandisk Extreme Plus formatted in FAT32. I

~ 9 days ago. Not sure what good GPS will do in CWM but it's updated to almost the same day as the update released, if not newer.
 

jce2005

Senior Member
Jul 13, 2009
174
27
[QUOTE
I was just playing around with mine and backing up to sd1 seems to work on mine. What are you using for an sd card? model, size, format etc? I was playing with formats on mine so I can't remember if it's FAT32 or EXFAT, I will check. I can Backup and restore on sdcard1 just fine.
Mine is a 32GB Sandisk Extreme Plus formatted in FAT32. I[/QUOTE]


Mine is a Sandisk Ultra 128GB FAT32

I cannot mount sdcard1.... I think I tried everything.... Any other ideas ?
 
  • Like
Reactions: twistedumbrella
I was just playing around with mine and backing up to sd1 seems to work on mine. What are you using for an sd card? model, size, format etc? I was playing with formats on mine so I can't remember if it's FAT32 or EXFAT, I will check. I can Backup and restore on sdcard1 just fine.
Mine is a 32GB Sandisk Extreme Plus formatted in FAT32. I


Mine is a Sandisk Ultra 128GB FAT32

I cannot mount sdcard1.... I think I tried everything.... Any other ideas ?
Some of the extra high capacity cards have issues with Android even if the device claims to be compatible.

If formatting the card in recovery doesn't work and it works on other devices, little can be done. If it's not mounting on any device, SanDisk will replace it if you contact them.
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 19
    I am not responsible for anything that happens while installing this recovery



    Installation:

    Download the attached recovery.img. You must have your bootloader unlocked before following this guide please refer HERE . You do not have to root your device to complete this installation.

    To permanently flash to recovery partition

    Code:
    fastboot flash recovery recovery.img

    To test the recovery image use

    Code:
    fastboot boot recovery.img

    To install SuperSu/Root your device use the flashable zip from Chainfire's thread. No direct links let's give him credits
    http://forum.xda-developers.com/showthread.php?t=1538053

    Current issues:
    It appears to be rotated 180 degrees the wrong way. It's rotated that way due to the framebuffer. Don't worry it does not effect the performance in any way.

    Source:

    device https://github.com/C457/android_device_nvidia_wx_na_wf

    kernel https://github.com/C457/android_kernel_nvidia_ardbeg

    If you want to build the recovery to fix the 180 degree rotated issue you will need one patch from google

    http://gerrit.vanir.co:8080/#/c/324/

    Thanks

    Huge thanks to @Keithn for testing all my bad images

    If you would like to help me purchase this tablet follow the link below
    http://www.gofundme.com/dbb08k
    8
    Hi guys,

    if I try in CWM to flash the " productionBL-droid-signed-wx_na_do-full_ota-29082_493.9700.zip " file it aborts with this error : " This Package is for "shieldtablet" devices; this is a "ardbeg"

    Anyone knows what the problem might be ?

    Thx,

    jce
    I had this problem too. I'm using the recovery from a few pages back that fixes the upside-down issue, so maybe you're using the same one? The "ro.product.device" in that one says "ardbeg" instead of shieldtablet. I recompiled it to use shieldtablet and then was able to flash the full OTA fine through CWM.

    Here's the updated recovery. You'll need to unzip it and flash through fastboot or adb.

    Code:
    adb shell
    su
    dd if=/data/media/0/recovery.img of=/dev/block/platform/sdhci-tegra.3/by-name/SOS

    or

    Code:
    fastboot flash recovery recovery.img
    8
    How can i flash the new 5.0.1 update using this recovery or do i have to go back to stock?
    You don't have to go back to stock. All you need to do is:
    1. Flash the full update package in recovery, as in the 700+MB one for that very device (Wifi, or LTE), not the 80ish MB one. Find them here:
    wifi: http://ota.nvidia.com/ota/rom/productionBL-droid-signed-wx_na_wf-full_ota-29082_493.9700.zip
    US-LTE: http://ota.nvidia.com/ota/rom/productionBL-droid-signed-wx_na_do-full_ota-29082_493.9700.zip

    2. Once this is flashed, reboot the device. You are probably gonna lose recovery at this point. You can find CWM here (http://forum.xda-developers.com/shi.../recovery-cwm-recovery-nvidia-shield-t2848064), and supersu here (http://download.chainfire.eu/641/SuperSU/UPDATE-SuperSU-v2.40.zip put it somewhere on your tablet). Then Flash them following this procedure:
    -adb reboot bootloader
    -fastboot flash recovery recovery.img
    -don't do "fastboot reboot" yet. I found CWM won't stick on the tablet for some reason. What you
    need to do instead is to go to recovery mode by directly choosing the "recovery mode" option on
    the tablet while it's still in bootloader mode.
    -Once you're in recovery mode, flash supersu zip file
    - Reboot, and profit
    4
    Uploaded new recovery.img it's using normal layout as nvidia kernel makes it go that direction I decided to just swap volume up and down keys.
    4
    Current issues:
    It appears to be rotated 180 degrees the wrong way. It's rotated that way due to the framebuffer. Don't worry it does not effect the performance in any way.

    Couldn't decide if it would be worth starting an entirely separate thread, but I fixed the framebuffer so that it's oriented correctly. I thought about creating a merge request, but I was using NVIDIA's Tegra device tree, which is...really different.

    In any case, here's my device tree. The bulk of the fix is in common/recovery/graphics.c, in the gr_flip() method. In the default graphics.c file, this method basically just does a memcpy() from memory to the framebuffer. The modified version is this:

    Code:
    void gr_flip(void)
    {
            GGLContext *gl = gr_context;
    
            /* swap front and back buffers */
            if (double_buffering)
                gr_active_fb = (gr_active_fb + 1) & 1;
    
            int buffer = 0;
            int fbsize = fi.line_length * vi.yres;
    
            // Copy the in-memory buffer into the buffer we're about to make
            // active, but reverse the order of the pixels.
            for (buffer = 0; buffer < fbsize; buffer += 4)
            {
                const char *src = (char *)gr_mem_surface.data;
                char *dst = (char *)gr_framebuffer[gr_active_fb].data;
    
                // Since we're reversing the buffer data, we need to flip the order
                // of the subpixel values, too. Otherwise they'll be backwards.
                dst[(fbsize-(buffer+4))] = src[buffer-PIXEL_OFFSET];
                dst[(fbsize-(buffer+3))] = src[buffer+1-PIXEL_OFFSET];
                dst[(fbsize-(buffer+2))] = src[buffer+2-PIXEL_OFFSET];
                dst[(fbsize-(buffer+1))] = src[buffer+3-PIXEL_OFFSET];
            }
    
            /* inform the display driver */
            set_active_framebuffer(gr_active_fb);
    }

    There are a few other smallish adjustments that I had to make in order to get everything lined up correctly. That offset is because without it I was getting some weird padding on the right side of the screen, for example. Anyway, I've got it running on my LTE Shield and haven't had any issues. Did a backup, performed a partial restore, flashed SuperSu, etc.

    If anyone wants to try the recovery, I've attached a zipped copy of the image. This is NOT a zip that you can flash from your current recovery, I just zipped it because the raw image exceeds XDA's file upload limit apparently. Unzip the image, then flash it or boot it via fastboot or Flashify or whatnot, just like any other recovery image. MD5 for the image (not the zip) should be 7959f08d9266b60da46f44ab4333c92a. I make no promises, but as I said, it's working fine on my Shield.