-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nexus 7 2012 becomes unresponsive after step 4 #8
Comments
i have a feeling that the use of a VM is causing the issue. can you try an ubuntu live boot usb or something? APX mode is very finicky, and even more so when using fusee. any extra usb reenumeration caused by the usb passthrough could be making it freeze. |
Thanks for the quick reply, in ubuntu USB live i get a little further, the device boots up to google logo after step 6, but i can't run step 7, even with --sync ubuntu@ubuntu:~/tegra30_debrick$ sudo ./utils/nvflash_v1.13.87205_miniloader_patched --setbct --bct ./bct/nexus_7_grouper_bct.bin --configfile ./utils/flash.cfg --bl ./bootloader/bootloader-grouper-4.23.img --go sending file: ./bct/nexus_7_grouper_bct.bin
ubuntu@ubuntu:~/tegra30_debrick$ sudo ./utils/nvflash_v1.13.87205_miniloader_patched --resume --download EBT bootloader/bootloader-grouper-4.23.img --configfile ./utils/flash.cfg --sync ubuntu@ubuntu:~/tegra30_debrick$ |
it might be an issue with faulty emmc flash. what caused the brick in the first place? see comments here #5 (comment) |
Unaware what caused it to brick, acquired the device in a bricked state. |
yeah mine does the same as the comments of that post, looks like hardware failure. Shame, seeing the google logo gave me some hope. |
yeah, the logo just means the bootloader sent via nvflash has initialized to the nv3pserver mode :/ unsure if it's a common thing for n7 emmc to go bad or the issues section here is a skewed sample ;) |
I think they used the cheapest emmc from shenzhen market for Nexus 7...i've seen 3 of my own fail under warranty. Oh well. More ewaste. Thanks for all the help. You do good work. |
Replacing an eMMC chip is a relatively trivial repair, and with the debrick
it affords the opportunity to upgrade the size.
…On Wed, Jan 26, 2022, 21:25 Garland Wiersema ***@***.***> wrote:
Closed #8 <#8>.
—
Reply to this email directly, view it on GitHub
<#8 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFWB7K2PB3RWYQ6KZWXOBLUYCUI5ANCNFSM5M4RV5JA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Is there a clear guide on how to do this? The most I’ve ever soldered were a few caps on an old motherboard but if it’s trivial like you say, sounds like fun. |
it'd definitely not be easy for me, as i have enough trouble aligning small chips like SOIC-8, let alone a BGA where you can't actually see the alignment or solder. you'd also need to somehow repopulate the blank flash (before or after?). this would probably require a full flash image from a donor n7 to make sure all of the bits and pieces (calibration data partitions? i've seen them used for touchscreens and wifi chips, etc.) are in place. the BCT / bootloader would then need to be rewritten using nvflash as it's encrypted with a per-device SBK (secure boot key). maybe you could get away without a donor image if you used the flash partition config at utils/flash.cfg (for 16GB) and used something other than stock android. i have never attempted to flash/rewrite the partition table though. step 17 here has pics and part # for the emmc: https://www.ifixit.com/Teardown/Nexus+7+Teardown/9623 |
Hi,
I'm trying to unbrick a Nexus 7 stuck in APX mode. I'm doing this in Ubuntu 16.04, running as a VM in VirtualBox on a MacBook Pro 15" 2014. USB is set to USB3. After the
sudo ./fusee-launcher/fusee-launcher.py ./payload/uart_payload_n7.bin -P 7330
command executes, the device becomes unresponsive. the only way to re-establish communications is to reboot the device (holding power and volume up for 10 secs) but alas the command needs to be run again, thus putting me in a loop.Full output:
`ubuntu@ubuntu-VirtualBox:~/tegra30_debrick$ sudo ./fusee-launcher/fusee-launcher.py ./payload/uart_payload_n7.bin -P 7330
2022-01-27 02:07:40,747 INFO:usb.core:find(): using backend "usb.backend.libusb1"
Important note: on desktop Linux systems, we currently require an XHCI host controller.
A good way to ensure you're likely using an XHCI backend is to plug your
device into a blue 'USB 3' port.
Identified a Linux system; setting up the appropriate backend.
intermezzo_size: 0x00000078
target_payload_size: 0x000005ee
Found a Tegra with Device ID: b'051634b748325d01'
Stack snapshot: b'0000000000000000100000003c9f0040'
EndpointStatus_stack_addr: 0x40009f3c
ProcessSetupPacket SP: 0x40009f30
InnerMemcpy LR stack addr: 0x40009f20
overwrite_len: 0x00004f20
overwrite_payload_off: 0x00004de0
payload_first_length: 0x000005ee
overwrite_payload_off: 0x00004de0
payload_second_length: 0x00000000
b'00a0004000300040ee05000000000000'
Setting rcm msg size to 0x00030064
RCM payload (len_insecure): b'64000300'
Setting ourselves up to smash the stack...
Payload offset of intermezzo: 0x00000074
overwrite_payload_off: 0x00004de0
overwrite_len: 0x00004f20
payload_overwrite_len: 0x00004e5c
overwrite_payload_off: 0x00004de0
smash_padding: 0x000047f2
overwrite_payload_off: 0x00004de0
Uploading payload...
txing 20480 bytes total
txing 4096 bytes (0 already sent) to buf[0] 0x40003000
txing 4096 bytes (4096 already sent) to buf[1] 0x40005000
txing 4096 bytes (8192 already sent) to buf[0] 0x40003000
txing 4096 bytes (12288 already sent) to buf[1] 0x40005000
txing 4096 bytes (16384 already sent) to buf[0] 0x40003000
Smashing the stack...
sending status request with length 0x00004f20
The USB device stopped responding-- sure smells like we've smashed its stack. :)
Launch complete!
ubuntu@ubuntu-VirtualBox:~/tegra30_debrick$ dmesg
[ 883.804105] usb 1-2: new high-speed USB device number 11 using xhci_hcd
[ 883.951300] usb 1-2: New USB device found, idVendor=0955, idProduct=7330
[ 883.951301] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 883.951302] usb 1-2: Product: APX
[ 883.951303] usb 1-2: Manufacturer: NVIDIA Corp.
[ 893.427639] usb 1-2: USB disconnect, device number 11
[ 1195.883616] usb 1-2: new high-speed USB device number 12 using xhci_hcd
[ 1196.033344] usb 1-2: New USB device found, idVendor=0955, idProduct=7330
[ 1196.033347] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1196.033348] usb 1-2: Product: APX
[ 1196.033349] usb 1-2: Manufacturer: NVIDIA Corp.
ubuntu@ubuntu-VirtualBox:~/tegra30_debrick$ sudo ./utils/nvflash_v1.13.87205 --getbct --bct BCT_READBACK_N7.BIN --configfile ./utils/flash.cfg
Nvflash v1.13.87205 started
`
The text was updated successfully, but these errors were encountered: