No response (time out?) after at step 6 booting from APX to fastboot #9
Comments
|
try skipping step 5. see note from step 5: "Note: APX/nvflash will become unresponsive after this completes successfully - you'll need to cycle power and repeat steps 1 through 4" |
|
Skip the quote and go to below.
Ok disregard the above I carefully reviewed the process. However now after running the command (step 7) with nv3pserver to reflash bootloader: Looks like there is a corrupt partition table? If so, is this the end? |
|
may be bad emmc :/ see #8 my suggestion there was to run the following in lieu of step 7: that should fetch the BCT and partition table using raw emmc read commands. if it fails to fetch, it hints at a hardware issue. if it does fetch without error, it might be that the flash was erased somehow. the flash.cfg is for 16GB, but i have not tried repartitioning a device using that. it's just to make nvflash happy (some of the commands require a .cfg to be provided, even though it's not otherwise used). |
|
Thank you for the recommendation, I will see what can be done and if I can get my hands on a non VM Linux. Will report back. |
|
Here is the result: This is from VM Linux. (haven't t had time to setup a USB bootable Linux yet but is on the to-do list). End of the road or not yet? I can also get my hands on another working N7 in a week, will that help? (saw there is a method to revive bricked N7s using another working N7). Thanks! |
|
i think the if emmc is bad then probably the other method using another n7 to generate a nvflash blob wouldn't help, but i'd be curious of the result regardless. |
|
Agree. I'll attempt the other method as a hail mary and report back. Would you know if the emmc replacement is plug and play or solder and burn fingers? |
|
it'd require soldering. it would also require somehow getting the correct filesystem/partitions onto the chip. see my reply here: #8 (comment) |
|
Hi @tofurky, First, let me thank for this great work of yours. I'm having a similar problem. Every step goes as expected, but when I run the command from step 7:
I get this output: And it just sits there doing nothing. I ran the command you suggested:
And it runs just fine. I attach to this posts the zip result of this command. Is there anything that can be done to recover it or is it just bricked for good? Thanks in advance! |
|
@afliw at a glance the file you posted looks like it had an intact bct and bootloader, though the apparent partition layout doesn't quite line up with what i'd expect per https://github.com/tofurky/tegra30_debrick/blob/master/utils/flash.cfg do you know how the tablet was originally bricked? and can you clarify the model #? |
|
Hey @tofurky, thanks for your answer and your time. The table is a Nexus 7 32GB (grouper). I bricked on 2014, trying to do something like this: If I recall correctly, I messed up some step and boom, bricked... 😅 I recently found the tablet lying around and though of try to bring it back. In 2014, the only way was with a previously saved blob as you know, and when I found your guide, well, I just had to try it. I have tried with both configfiles, yours (16GB) and another one I've found for the 32GB version, but with no luck. Every time I try to flash anything, it just get stuck. I can do rawdeviceread just fine, but it won't flash anything, just shows the Google logo (no battery low warning). |
|
were you able to boot into fastboot/recovery before running any of the nvflash commands in this repo? or was it booting directly to APX mode? |
|
No, can't boot into fastboot nor recovery. If I connect it bare, I get this: And keeps doing that. When I pressed Vol Up + Power, I get the APX mode: When I ran the command 6 of your guide, I got the Google logo screen, which made me think maybe there's hope. But no matter how much I try, can get step 7 to work... not with backed up BCT or the repo's one, --sync or no --sync, flash16 o flash32 config file, it just doesn't want to flash any image. Every time it gets stuck in "sending file". |
|
After several retries, it also has thrown this error: |
|
could you try these steps from a fresh power cycle into APX mode and post partitions.txt if it reads it? i found a 32gb n7 nvflash cfg at https://www.mediafire.com/file/j90hc1dfz58aytq/flashcfg.zip (from https://forum.xda-developers.com/t/tutorial-how-to-unbrick-nexus-7-without-blob-bin-requires-another-nexus-7-2012.4083879/) and it matches up to what i see in the --rawdeviceread output you posted, but it seems like the LNX partition at that URL is too small (1MB). anyways, my thought was taking a step from the the ouya debrick process (flashing 8MB of zeroes - dependent on the size of LNX) to get it to switch from nv3pserver mode to fastboot mode and trying to reflash it from there ( if for some odd reason it was f2fs data on other partitions causing the bootloader to bug out, you could use fastboot to erase them after doing the LNX zeroes trick. assuming the f2fs data is causing an issue somehow, nvflash also has a --format_partition command (which i've not used) that might stand in for 'fastboot erase' if it's not possible to enter via the LNX trick. |
|
Ok, here's the partitions.txt file, the command ran just fine. I'm seeing a difference. In this output, there's no RDO partition and yes, LNX size is different than the flash32.cfg file I was using (it's the same you pointed out in your post) As I write this, I fixed the size of LNX partition in the flash32.cfg that you pointed out, replacing its size from 1Mb to 8Mb, and I used this command: In dmesg I saw this: Looks like it worked, now I can see the device in fastboot, also a "Start" button appeared in the screen above the Google logo. I'm unsure what to do next, should I try to flash the full stock image or do I have to flash the bootloader first? EDIT: Tried flashing bootloader with no luck: 😔 |
|
I'd try "fastboot flash bootloader bootloader-grouper-4.23.img"
…On Tue, Jun 14, 2022, 10:40 PM afliw ***@***.***> wrote:
Ok, here's the partitions.txt
<https://github.com/tofurky/tegra30_debrick/files/8905152/partitions.txt>
file, the command ran just fine.
I'm seeing a difference. In this output, there's no RDO partition and yes,
LNX size is different than the flash32.cfg file I was using (it's the same
you pointed out in your post)
As I write this, I fixed the size of LNX partition in the flash32.cfg that
you pointed out, replacing its size from 1Mb to 8Mb, and I used this
command:
> sudo ./utils/nvflash_v1.13.87205 --resume --format_partition 8
Nvflash v1.13.87205 started
[resume mode]
Formatting partition 8 LNX please wait.. done!
failed executing command 26 NvError 0x120002
command failure: sync failed (bad data)
bootloader status: Bct Write Failed (code: 22) message: nverror:0x42008 (0x6042008) flags: 0
In dmesg I saw this:
[Tue Jun 14 23:25:31 2022] usb 1-3: USB disconnect, device number 43
[Tue Jun 14 23:25:31 2022] usb 1-3: new high-speed USB device number 44 using xhci_hcd
[Tue Jun 14 23:25:31 2022] usb 1-3: New USB device found, idVendor=18d1, idProduct=4e40, bcdDevice= 0.00
[Tue Jun 14 23:25:31 2022] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Tue Jun 14 23:25:31 2022] usb 1-3: Product: Android
[Tue Jun 14 23:25:31 2022] usb 1-3: Manufacturer: Google, Inc
[Tue Jun 14 23:25:31 2022] usb 1-3: SerialNumber: 015d2856b65c0015
Looks like it worked, now I can see the device in fastboot, also a "Start"
button appeared in the screen above the Google logo.
I'm unsure what to do next, should I try to flash the full stock image or
do I have to flash the bootloader first?
—
Reply to this email directly, view it on GitHub
<#9 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA7AR2OBIHNKLTY23P3MVFTVPE7A5ANCNFSM5SJPFOAQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
running low on ideas here. can you provide the original BCT you hopefully backed up from the tablet before overwriting it with --sync? i suppose it's worth a shot to try an older version of the grouper bootloader (rather than bootloader-grouper-4.23.img) but it's a shot in the dark. could also try erasing the partitions you converted to f2fs. you could dump them with nvflash and examine the beginning of the partitions with a hex editor (e.g. xxd file.bin|less) to see if it has ext4 or f2fs magic bytes. a possible last ditch effort would be to erase both the BCT and bootloader partitions and try to start fresh (rewrite bootloader + BCT in one go). uart would be most useful to identify the issue, but it was really quite difficult to solder wires on there, it's very small solder pads. |
|
also, i was able to obtain a copy of a known-good 32G partition table, so if you provide a dump of PT i can check to see if it was somehow messed up.
|
|
Me too, I've a tried a lot by now, with nvflash, fastboot, whelie and even managed to boot the flatline_grouper.img from fastboot and was able to use adb, but nothing seems to work from there either. Here's the BCT_READBACK_N7.BIN.gz, but I'm pretty sure is useless, I think the first time I skipped step 5, sorry. It occurred to me too to use an older bootloader, but got the same results. What do you mean by erasing partitions? Format them? If that is the case, I have already formatted every partition that nvflash and fastboot have let me.
How would I have to proceed in that case?
I'm sure it would, but it's way beyond my capabilities...
I will post it as soon as I can, but now I'm seeing something that I didn't see before. I got the message |
|
er, did you erase every partition? not all can be restored via android stock restore. others like PT (partition table) and GPT ("backup" gpt partition table at end of flash) should not be touched. i've erased bct in the past with this, i wouldn't suggest doing it before verifying the integrity of your partition table though: |
|
Well, I did this: And also tried the Here is the PT.bin.gz I got from running: Is it possible that there's something physically wrong with it? I mean, some hardware fault? |
|
partition table looks correct. the one i compared it to was 3g i guess (had RDO radio partition, yours doesn't). you could try a rawdevicewrite of zeroes to the EBT (bootloader) partition. if it fails, then yeah, probably a hardware issue. note that rawdevicewrite is risky in general (relatively easy to get the wrong offset and nuke something you didn't mean to). from the partitions.txt you provided: this also matches up to what i get when running a utility to parse the PT.bin.gz you provided. |
I ran this command several times, sometimes it throws this error: And sometimes it gets stuck with this: I also tried this: Can you make anything of this? Here's what was read: EBT.bin.gz |
|
it successfully overwrote EBT with zeroes per the EBT.bin.gz. but no, i can't make sense of it. i suppose the inconsistent success/failure could hint at a usb signal integrity issue (try a different cable?). did you try re-writing the bootloader after zeroing out the EBT partition? if that still fails, you could try the last ditch effort of wiping BCT+EBT: then power cycle the tablet (it should boot straight to APX without coercing) and go through the steps, making sure to use the --sync option where applicable |
|
Sorry for the delay, hadn't had time to try your suggestions. Regrettably, it didn't work. Trying to flash all zeros in the BCT partition works normally, but not with the EBT, same problem as before. Every time I try to do some write operation with (or format) the EBT partition, it fails. Also tried with 4 different cables, same results with each of them... 😔 Is it possible that the EBT partition is broken for writing but not for reading? Is it possible to repartition and move the EBT to another sector? |
|
i've not tried repartioning. i do not know if it would work with the patched nvflash. i was under the impression that you were able to successfully write the EBT partition with --rawdevicewrite - the readback showed all zeroes. you could try again with a file filled with a pattern - e.g. then read it back. the resulting file should do this if read back successfully: anyways, i'm unfortunately not sure what the issue might be. i suppose it could be misbehaving emmc. |
Steps 1 to 5 working properly from what I can tell, they executed as per instructions, however after executing step 6
The command appears to hang, and after 45 minutes I had to force close the terminal.
Any ideas what might cause this behaviour?
P.S. I'm a beginner.
Thanks!
The text was updated successfully, but these errors were encountered: