[WARNING][URGENT] N7 grouper (2012 WiFi) bootloader .img files from Google

Search This thread
By:
Advanced…
R

RusherDude

Senior Member
Aug 24, 2012
2,013
623
bftb0 said:
Executive Summary:

...

3) Somebody from Google/Asus screwed up royally and put the OTA (preamble-prefixed) bootloader file into the JWR66Y (full) factory Image; similarly the bootloader ".img" file in the KOT49H image is also screwed up - it starts with "BOOTLDR!" rather than an arm objcode near branch ("ea000010 == b[ranch] 48"). It is also a wildly different size than prior bootloader .img files. What's up Google?
[/b]
Click to expand...
Click to collapse

They didn't fix the KOT49H image right? It has still a bootloader different than all the others?
 
shawnbrennan55

shawnbrennan55

Senior Member
Mar 24, 2014
608
281
  • Like
Reactions: ktwist
C

corkiejp

Senior Member
Sep 27, 2012
2,045
917
Cork
www.boards.ie
  • Like
Reactions: ktwist
genericfu

genericfu

Member
Apr 11, 2015
36
38
I just tried flashing the bootloader from the factory 5.1 (LMY47D) Nakasi image and I still get the old InvalidState image.
Perhaps still not fixed?
 
genericfu

genericfu

Member
Apr 11, 2015
36
38
I was able to flash the bootloader by using the flash-all script instead of manually just flashing boot.img. I have no idea why, I didn't redownload it.
 
Wish39

Wish39

Senior Member
Jan 13, 2015
242
89
I will notify Google about this.
Oh, and this may be the reason why people's Nexus 5 and 7's are getting bricked left and right. Maybe you should check the Nexus 5 bootloaders too.
 
AndDiSa

AndDiSa

Senior Member
Dec 2, 2009
3,705
5,077
Heidelberg
HTC Desire
Nexus 7
You need to read correctly: he tried to flash the wrong file to the boot loader partition and that failed (fortunately!) but flashall worked because this script was doing it right.
 
C

corkiejp

Senior Member
Sep 27, 2012
2,045
917
Cork
www.boards.ie
Wish39 said:
I will notify Google about this.
Oh, and this may be the reason why people's Nexus 5 and 7's are getting bricked left and right.
Click to expand...
Click to collapse

It's the Nexus 7 (2013) that where getting bricked! Not the 2012 version which this thread is about!

The incorrect bootloader in the factory images for the Nexus 7 (2012) wasn't really a problem that could cause a Brick (unless someone was really trying to force these bootloaders on to there devices). Most of the time the flashing of the bootloader would just fail and the correct current one would remain on the device.
 
Wish39

Wish39

Senior Member
Jan 13, 2015
242
89
Hmmm. I've seen owners of BOTH versions of the Nexus 7 finding that their devices are just bricking themselves. The 2013's big reason is that it just shuts off and bricks itself, while 2012's is when you install the 5.1 OTA and...bricked.

Sent from my HTC One running Lollipop
 
R

RusherDude

Senior Member
Aug 24, 2012
2,013
623
genericfu said:
I was able to flash the bootloader by using the flash-all script instead of manually just flashing boot.img. I have no idea why, I didn't redownload it.
Click to expand...
Click to collapse

You were really trying to flash a boot.img to the bootloader?

Good stuff it has some protection.. why don't you try to dd over the sbl partition next to see if that works? You seem to want to brick that.. (don't do it..)

---------- Post added at 01:14 AM ---------- Previous post was at 01:13 AM ----------
kibmcz said:
It seems google finally updated the bootloader in 5.1.1 (lmy47v) to be correct lol.
Click to expand...
Click to collapse

Google updated most of the wrong bootloaders recently, could you update the table to reflect that? I think that everything but the "wrong device" one is fixed :)
 
You must log in or register to reply here.

Similar threads

Step666
  • Locked
The all-in-one Play Store orders/shipping/etc thread
Replies
19K
Views
2M
ashclepdia
ashclepdia
bcvictory
  • Poll
[GUIDE] *19/8 UPDATE!* 4.3 RESULTS! N7 'Best' Kernel (Performance & Battery Tests)
Replies
563
Views
248K
Y
yattamove
b00mb00mchuck
Nexus 7 WiFi antenna mod CRUSHES WORLD RECORD!!! 12/16/2012 THE MAGIC MILE
Replies
255
Views
194K
b00mb00mchuck
b00mb00mchuck
oldblue910
[REF] Nexus 7 Stock OTA URLs
Replies
2K
Views
571K
spdevs
spdevs
nhshah7
[Root][JB 4.2] Root your Nexus 7 without unlocking bootloader. (djrbliss motochopper)
Replies
374
Views
202K
D
Da_Hora

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 33
    B
    bftb0
    EDIT 12/8/2015 - THIS THREAD IS NOW OBSOLETE.

    In Early April 2015, Google retroactively changed a large number of prior factory images for nakasi/grouper (possibly nakasig too). Read this thread from post #57 onward.

    Thank to wugfresh for noticing the changes.

    Note that because previous binary images are now "in the wild" (or, you might have retained your own archives) you still need to be aware of what you are flashing - cross-check your checksums, folks.



    Executive Summary:

    1) There are at least THREE different bootloader files from Google/Asus that are all labeled with the identical version number "4.23". The versions distributed with the JWR66Y, KOT49H, KUT48L, KUT48P, and LRX21P Google factory images are INVALID. If you want a 4.23 bootloader ".img" file, get it from any of the (JWR66V, KRT16O, KRT16S) Google factory images

    2) The "bootloader.raw" files contained in the OTA update .zip files ARE PREFIXED WITH A 76-byte PREAMBLE, and thus are NOT identical to the bootloader ".img" files distributed by Google in their full factory image distros. They should never be used with fastboot.

    3) Somebody from Google/Asus screwed up royally and put the OTA (preamble-prefixed) bootloader file into the JWR66Y (full) factory Image; similarly the bootloader ".img" file in the KOT49H image is also screwed up - it starts with "BOOTLDR!" rather than an arm objcode near branch ("ea000010 == b[ranch] 48"). It is also a wildly different size than prior bootloader .img files. What's up Google?


    I didn't examine any of the tilapia full factory images or OTA zip files to check them. You've been warned!

    details:

    Code: 
    GROUPER (N7 Wifi-Only, 2012) BOOTLOADERS 

DERIVED FROM Google "Factory Images":

BYTES    MD5SUM				           ROM     FACTORY_IMAGE_FILENAME                       strings *.img | grep BOOTLOADER

2142784  f5f8c0dd160ef92c601311a0c9054118  JZO54K  ./nakasi-jzo54k/bootloader-grouper-3.41.img   BOOTLOADER VERSION - 3.41

2146892  a119629c89ad06c7e49bebd260df9cf3  JOP40C  ./nakasi-jop40c/bootloader-grouper-4.13.img   BOOTLOADER VERSION - 4.13
2146892  a119629c89ad06c7e49bebd260df9cf3  JOP40D  ./nakasi-jop40d/bootloader-grouper-4.13.img   BOOTLOADER VERSION - 4.13

2146892  bffa744a6847b5bede2bf445427ef80e  JDQ39   ./nakasi-jdq39/bootloader-grouper-4.18.img    BOOTLOADER VERSION - 4.18

2150992  df53028033c9eccf4fe5ba7bc198ce24  JWR66V  ./nakasi-jwr66v/bootloader-grouper-4.23.img   BOOTLOADER VERSION - 4.23
[color=red]2151068  5bdb2e87370cdb1a7ea14bb0c3e21390[/color]  JWR66Y  ./nakasi-jwr66y/bootloader-grouper-4.23.img   BOOTLOADER VERSION - 4.23
2150992  df53028033c9eccf4fe5ba7bc198ce24  KRT16O  ./nakasi-krt16o/bootloader-grouper-4.23.img   BOOTLOADER VERSION - 4.23
2150992  df53028033c9eccf4fe5ba7bc198ce24  KRT16S  ./nakasi-krt16s/bootloader-grouper-4.23.img   BOOTLOADER VERSION - 4.23
[color=red]4005632  797a8ddfe19bfe4c485f8a8c119f1bdd[/color]  KOT49H  ./nakasi-kot49h/bootloader-grouper-4.23.img   BOOTLOADER VERSION - %s
[color=red]2151068  5bdb2e87370cdb1a7ea14bb0c3e21390[/color]  KTU84L ./nakasi-ktu84l/bootloader-grouper-4.23.img  BOOTLOADER VERSION - 4.23
[color=red]2151068  5bdb2e87370cdb1a7ea14bb0c3e21390[/color]  KTU84P ./nakasi-ktu84p/bootloader-grouper-4.23.img  BOOTLOADER VERSION - 4.23
[color=red]2151068  5bdb2e87370cdb1a7ea14bb0c3e21390[/color]  LRX21P ./nakasi-lrx21p/bootloader-grouper-4.23.img  BOOTLOADER VERSION - 4.23

    What sloppiness. Hard to say whether this is a Google fumble or an Asus fumble; perhaps something fell in the cracks between them.


    What are the OTA 76-byte preambles of the "bootloader.raw" files? I'm not sure exactly. Perhaps they are nothing more than a signature used to "alert" the existing bootloader that a replacement bootloader has been dropped into the USP partition. (I suppose that all versions of the bootloader look at the USP partition when they first boot up to check for the presence of an update; the same technique may also be used by tilapia devices for radio firmware, but that's speculation) These prefixes are also not identical to each other; they seem to vary in only a few bytes from version to version, e.g.:

    Code: 
    nakasi-JZO54K-from-JRO03S.d41da8f6 bootloader.raw   (v 3.41)

00000000  4d 53 4d 2d 52 41 44 49  4f 2d 55 50 44 41 54 45  |MSM-RADIO-UPDATE|
00000010  00 00 01 00 3c 00 00 00  3c 00 00 00 01 00 00 00  |....<...<.......|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 45 42 54 00  |............EBT.|
00000040  4c 00 00 00 [color=red]40 b2 20 00[/color]  01 00 00 00              |L...@. .....|
0000004c


nakasi-JOP40D-from-JZO54K.c01f18e0 bootloader.raw (v 4.13)

00000000  4d 53 4d 2d 52 41 44 49  4f 2d 55 50 44 41 54 45  |MSM-RADIO-UPDATE|
00000010  00 00 01 00 3c 00 00 00  3c 00 00 00 01 00 00 00  |....<...<.......|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 45 42 54 00  |............EBT.|
00000040  4c 00 00 00 [color=red]4c c2 20 00[/color]  01 00 00 00              |L...L. .....|
0000004c


nakasi-JDQ39-from-JZO54K.da55f917 bootloader.raw  (v 4.18)

00000000  4d 53 4d 2d 52 41 44 49  4f 2d 55 50 44 41 54 45  |MSM-RADIO-UPDATE|
00000010  00 00 01 00 3c 00 00 00  3c 00 00 00 01 00 00 00  |....<...<.......|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 45 42 54 00  |............EBT.|
00000040  4c 00 00 00 [color=red]4c c2 20 00[/color]  01 00 00 00              |L...L. .....|
0000004c


nakasi-JWR66V-from-JDQ39.ab67ca07 bootloader.raw    (v "4.23" rev0)

00000000  4d 53 4d 2d 52 41 44 49  4f 2d 55 50 44 41 54 45  |MSM-RADIO-UPDATE|
00000010  00 00 01 00 3c 00 00 00  3c 00 00 00 01 00 00 00  |....<...<.......|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 45 42 54 00  |............EBT.|
00000040  4c 00 00 00 [color=red]50 d2 20 00[/color]  01 00 00 00              |L...P. .....|
0000004c

    The differences that appear in these preambles are the 4-bytes sequence (shown highlighted above) which are exactly the (little-endian) length of the corresponding (non-preamble-prefixed) bootloader of the same "version".


    Recommendations:

    - Be extremely aware of where you get bootloader files from. The authoritative place to get the unadorned (no preamble) bootloaders are from the Google Factory Images. In the event you need older factory images which are not available from Google any longer, oldblue910 maintains a historical archive of both the factory images and individual OTA patch bundles.

    - "bootloader.raw" files should NEVER be flashed with fastboot.

    - bootloader ".img" files from the factory full-image distros won't do anything if flashed to the USP - they don't have the preamble that the (pre-existing) bootloader looks for.

    - If you must flash a bootloader, avoid the "4.23" bootloader .img files from the JWR66Y and KOT49H factory images. A valid 4.23 bootloader ".img" file has an MD5 signature of df53028033c9eccf4fe5ba7bc198ce24

    cheers


    * not sure what this file is; but it isn't a bootloader. While there is plenty of arm object code in there, It has almost 0% overlap of ascii strings greater than length 8 with the valid 4.23 bootloader from (e.g.) JWR66V. Possibly worth a look by folks that enjoy disassembly?
    View
    5
    B
    bftb0
    @andogeek10

    Some preliminaries - are 2012 versions of the N7 still being sold? If you are talking about the 2013 N7, then you are in the wrong forum. A lot of this stuff is device dependent (as you are finding out), so you should consult owners who have experience with the specific device you intend to purchase.

    andogeek10 said:
    i) If I update my android version using the OTA feature to 4.4.2 (KOT49H), it would also flash/update my bootloader, right?
    Click to expand...
    Click to collapse

    Well, you didn't say which version of bootloader you will be on. The OTAs are patch bundles, so if you already had the most recent bootloader, the OTA process would not apply it again.

    Having said that, there is no evidence that Google/Asus got any of the OTA bundles wrong - they are different from the "factory images" hosted by Google. So, first: this thread doesn't apply to OTAs, and second (see posts just above), the pre-existing bootloaders appear to do a sanity/crypto signing check before they allow the bootloader to be flashed into place for reals, so there is very little danger involved in an OTA. (Based on the recent reports, it isn't even obvious to me how folks would have been able to bork their bootloaders, unless they manually flashed it into place using a root shell and the dd command (either with the OS running or with a custom recovery running).


    andogeek10 said:
    So, according to this thread the bootloader included in that update is not right (or doesn't work properly?:confused: ) and then would I be required to flash the bootloader image from the KRT16S update?
    Click to expand...
    Click to collapse

    See above. If you were somehow able to flash a dud bootloader to the device, as soon as you power-cycled it, it would be a hard brick. I haven't been paying attention to the 2012 N7 forum recently, but I think the only thing that will save someone in that situation is that if they had previously prepared for the eventuality of a hard brick by using the flatline method.

    andogeek10 said:
    ii)I was reading through the flatline thread, and initially it seemed amazing that by generating a few blobs, you could unbrick your device. But, after reading a few pages ahead it seemed that many people were facing problems and it now seems a dangerous procedure. So my question is: Is it really recommended that an individual generate those blobs and by doing so, follow that nerve racking procedure?
    Click to expand...
    Click to collapse

    Folks will have different opinions about this, but honestly the only people who bork their bootloader are people that have extremely sloppy habits*. (Grab files from anywhere, never check file MD5 sigs, etc). Given that the set of instructions provided by the flatline devs are frankly quite vague on several points, you have to wonder if it is a good idea for folks with sloppy habits to be performing vaguely-described procedures, especially since the procedures involve the dangerous operation in question (flashing a bootloader).

    [Edit]* There is one high risk way a borking can happen that is probably easy for even skilled folks to accidentally perform; but only if they are in a hurry and not paying attention. And that is to accidentally do a "fastboot erase bootloader" when the intended command was "fastboot erase boot". Even in this case though, the existing bootloader is still present an running in memory; so as long as the tablet continues to run and you can communicate with it in fastboot mode, this type of mishap is correctable if you immediately flash back into place a valid bootloader. But if you turn the tablet off, it's a brick at that point. I don't really know why fastboot allows you to perform the erasure of the bootloader partition - it should be sufficient to simply flash something over the pre-existing bootloader. Something could still go wrong - as erasure of blocks always happens when flashing new data into flash memory; otoh, there is no delay between wiping and replacement with a valid image in the normal case. [/Edit]

    andogeek10 said:
    iii)If I were to flash a custom kernel, would it include a custom recovery or would I have to install a custom recovery using fastboot. And if the custom kernel will include a custom recovery, will overwrite the existing custom recovery?
    Click to expand...
    Click to collapse

    Custom kernels and recoveries are independent bootable images stored in different partitions. You don't get one with the other**, nor does one overwrite the other**. Generally, a conservative and safe 2012 N7 rooting sequence is

    0) Install the Android SDK and necessary drivers on your PC (no drivers needed for OS/X or Linux)
    1) unlock the bootloader using fastboot (this wipes any user data on the entire tablet)
    2) soft-boot a custom recovery image using fastboot, e.g.
    "fastboot boot openrecovery-twrp-2.6.3.1-grouper.img"
    3) use the soft-booted recovery to immediately take a FULL STOCK Nandroid backup - including the STOCK recovery!
    4) hard flash the custom recovery image (e.g. this time "fastboot flash recovery openrecovery-twrp-2.6.3.1-grouper.img", instead of "fastboot boot openrecovery-twrp-2.6.3.1-grouper.img")
    5) Use a "flashable zip" install of SuperSU (push the file to the device using adb with the recovery running, or put it on a USB key and plug that to the device with a OTG cable)
    6) If you want, you can make yet another Nandroid at this point to capture a baseline "lightly rooted Stock" backup.
    7) Immediately - before you do anything else - get copies of those full stock & lightly rooted stock backups someplace off of the tablet. (Note: TWRP supports OTG USB devices - you could have written the Nandroids to a USB thumb drive in steps 3 and 6 if you had wanted to.)

    8) Start doing what you will as far as rooting goes.


    Now, why did I give you the instructions above? Simple - the only way I have ever updated my bootloader is by taking a Nandroid backup of my current ROM, restoring the FULL STOCK Nandroid backup - INCLUDING THE FACTORY RECOVERY. This results in a device which is 100% stock and not even rooted... (but the bootloader is still unlocked). Then I take the OTA, and let the OTA do the dirty business.

    And when that completes, I repeat steps 2) - 6) all over - FOR THE NEW VERSION OF 100% STOCK INCLUDING THE STOCK RECOVERY.

    And check this out - I don't even use stock or lightly rooted stock as a daily driver.

    So why all the above nonsense?

    First because the OTA process has a bunch of crypto checks built in that protect you from hazards like the one you are anticipating. Second because running OTAs against modified ROMs will many times result in OTA failure.

    And third, so that I will have 100% stock Nandroid backups (including the stock recovery) for every stock release that has ever been issued for the tablet while I owned it. When I go to sell the thing, I can roll it back to 100% stock - for any release I want, lock the bootloader, perform a factory reset... and it will be as if it just came from the factory.

    Fourth, those stock releases will be fully capable of accepting future OTAs - unlike customized ROMs.

    good luck with your device(s)


    ** a boot image is = kernel + ramdisk. Both the "boot" and "recovery" images are boot images. In stock devices, the kernel used by the stock recovery is identical to the kernel used by the OS boot - they differ only in their ramdisk. So that means that when an OTA comes along that modifies the kernel used in the regular (Android) boot, the stock recovery partition will also get updated.

    In the recovery, the booting does not depend on anything in the /system or /data partition (kinda), whereas the regular boot image chains into full-up Android UI, apps, etc. So the recovery allows you to do offline maintenance of /system and (portions of) /data. What you might have seen on other devices, is that during application of the OTA, the recovery image is actually generated by a patch set that operates on the stock boot image. Quite literally, the recovery is generated from the boot image with a process that looks like

    /boot (image) + boot-to-recovery-patch.p -> recovery (image)

    Some older android phones would flash the stock recovery back into place (using the above method or similar) *every time the phone booted*. This was done via some scripts in /system. IIRC, something similar to this is present in Stock N7 releases, perhaps at /system/boot-from-recovery.p (and related init.d scripts) It is possible that the custom recoveries are aware of this and will relocate or remove this gearing for you (in the same way that they will offer to install SuperSU for you). But, if you notice that your custom recovery keeps getting replaced with the stock recovery when you use lightly-rooted-stock, this is the mechanism that does this.

    .
    View
    4
    B
    bftb0
    This is not a help thread. It would be in the help section if that were the case.

    If you take one thing away from this thread it is this:

    YOU SHOULD NOT BE ATTEMPTING TO FLASH THE BOOTLOADER using a bootloader file from known bad sources.
    (All the correct sources are listed in the OP.)


    If you take away two things from this thread, the 2nd item should be this:

    THERE IS NO NEED TO RE-FLASH THE 4.23 BOOTLOADER IF YOU ALREADY HAVE IT INSTALLED.


    If you want to take a 3rd thing away from this thread, here's my suggestion:

    THERE IS PROBABLY [size=+1]NEVER ANY REASON WHATSOEVER[/size] TO USE FASTBOOT TO **ERASE** THE BOOTLOADER.


    Sorry, but I don't know how this can be made any clearer.


    .
    View
    3
    S
    s107ken
    Hi, this weekend I flashed bootloader to my own N7 2012 3G(tilapia) many times.
    Describes in summary (but too looong), attached full report.

    I found JDQ39(4.2.2) and KRT16S(4.4) are only correct bootloader file?
    Grouper and Tilapia uses same bootloader.img?
    What happen google / asus software release?

    Code: 
    TILAPIA (N7 3G, 2012) BOOTLOADERS 
DERIVED FROM Google "Factory Images":
BYTES    MD5SUM				   ROM     FACTORY_IMAGE_FILENAME                        strings *.img | grep BOOTLOADER

2146892  bffa744a6847b5bede2bf445427ef80e  JDQ39   ./nakasig-jdq39/bootloader-tilapia-4.18.img   BOOTLOADER VERSION - 4.18
- - -    - - -                             JWR66V  (I don't have this factory image)             - - -
2151068  5bdb2e87370cdb1a7ea14bb0c3e21390  JWR66Y  ./nakasig-jwr66y/bootloader-tilapia-4.23.img  BOOTLOADER VERSION - 4.23
- - -    - - -                             KRT16O  bootloader & radio image didn't contain!!     - - -
2150992  df53028033c9eccf4fe5ba7bc198ce24  KRT16S  ./nakasig-krt16s/bootloader-tilapia-4.23.img  BOOTLOADER VERSION - 4.23
4005632  797a8ddfe19bfe4c485f8a8c119f1bdd  KOT49H  ./nakasig-kot49h/bootloader-tilapia-4.23.img  BOOTLOADER VERSION - %s

    JDQ39, KRT16S succeeded flash bootloader
    Code: 
    nakasig-jdq39# fastboot flash bootloader bootloader-tilapia-4.18.img 
sending 'bootloader' (2096 KB)...
OKAY [  0.338s]
writing 'bootloader'...
OKAY [  1.230s]
finished. total time: 1.569s

(bootloader screen left-top) "Signature match."

    JWR66Y, KOT49H failed flash bootloader
    Code: 
    nakasig-jwr66y# fastboot flash bootloader bootloader-tilapia-4.23.img 
sending 'bootloader' (2100 KB)...
OKAY [  0.335s]
writing 'bootloader'...
FAILED (remote: (InvalidState))
finished. total time: 0.469s

"Signature mismatch."
    View
    2
    GedBlake
    GedBlake
    bftb0 said:
    Hi Ged

    First, I should say that your comments here were what encouraged me to check all the (grouper) bootloader images from the Google "factory images" - it triggered a recollection that I had noticed a length difference between the OTA and fastboot versions of the bootloader files some time ago, so I went back and took a look. Thanks for giving me the incentive.



    There is a comment in that Flatline - Unbrickable Nexus 7 (Wi-Fi + 3G) thread to the effect of:



    ... but trying to read between the lines, I can not determine if Xcandescent's claims only apply if you leave the "patched" version of the android.mobi bootloader on the device, rather than using nvflash itself to put back a "stock" bootloader. Reading between the lines, it sounds like subsequently you have not tried using fastboot for flashing a bootloader... do I have that right?

    I guess I will put up a question on that thread and see if rayman or lilstevie respond...
    Click to expand...
    Click to collapse

    Hi, bftb0...

    It's good to see you around again. I must admit, that most of the stuff you post, I really, really don't understand:confused:... but I always learn something new:).

    Concerning flatline... Well, I ran it sometime back in October...

    I knew beforehand that there where known issues concerning fastboot flashing the bootloader from build JWR66Y (ie, it won't fastboot flash) so now I ALWAYS keep a copy of the v4.23 bootloader from build JWR66V stored on my laptop... which came in useful for the flatline procedure.

    The whole procedure revolves around flatlines Custom Recovery...

    Once I'd fastboot flashed the specially modified Flatline Custom Recovery (which is based on CWM) to the recovery partition, I then went into the ADVANCED option... and selected option 1: flash AndroidRoot BL... this flashes the AndroidRoot Custom Bootloader - (you don't actually flash this yourself - the Flatline Custom Recovery does it for you).

    Following the instructions to the letter, I then booted normally into Android.

    I shutdown my Nexus 7 completely, and rebooted into this modified AndroidRoot bootloader in fastboot mode... to discover that the version number had been 'downgraded' to v4.13. Nothing there signifies or indicates it is in fact the flatline AndroidRoot BL... it just looks like a regular v4.13 bootloader.

    After selecting the RECOVERY option in this modified bootloader, as you would normally, to get into either standard CWM or TWRP, it boots back into the Flatline Custom Recovery again.

    Selecting the ADVANCED option again... I now choose option 2: generate wheelie blobs... these blobs were then generated, which I subsequently found in /data/media/AndroidRoot on the Nexus 7 itself. Having made multiple copies of them, it was then just a matter of closing the operation by doing two things...

    *** fastboot flashed back to the normal v4.23 bootloader from build JWR66V...

    ...and after a normal reboot...

    *** fastboot flashed back to the version of TWRP I was using at the time...

    A summary

    1). I fastboot flashed the special Flatline Custom Recovery.
    2). In this special Custom Recovery, in the Advanced menu option, I selected option no.1... it flashed the AndroidRoot v4.13 bootloader.
    3). I rebooted normally into Android.
    4). I rebooted into the Flatline Custom Recovery again (via the bootloader).
    5). In the Advanced menu option, I selected 'generate wheelie blobs'.
    6). Once generated, I copied them from /data/media/AndroidRoot .

    -- Now to return everything back to normal...---

    7). I fastboot flashed the regular v4.23 bootloader from build JWR66V.
    8). I fastboot flashed the version of TWRP I was using at the time.

    I didn't need to use nvFlash to restore the standard bootloader... I just used the standard fastboot flash bootloader bootloader.img syntax, to reflash v4.23.

    And that's pretty much it really... obviously I haven't had the opportunity to test out those 'blobs'... and hopefully, I'll never have cause to:).

    Hope this helps.

    Rgrds,
    Ged.
    View

New posts