Nexus 7 2012 becomes unresponsive after step 4
garlandwiersema opened this issue · comments
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
`
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
Nvflash v1.13.87205 started
chip uid from BR is: 0x0000000000000000015d3248b7341605
rcm version 0X30001
System Information:
chip name: unknown
chip id: 0x30 major: 1 minor: 3
chip sku: 0x83
chip uid: 0x0000000000000000015d3248b7341605
macrovision: disabled
hdcp: enabled
jtag: disabled
sbk burned: true
dk burned: true
boot device: emmc
operating mode: 3
device config strap: 1
device config fuse: 17
sdram config strap: 1
sending file: ./bct/nexus_7_grouper_bct.bin
- 6128/6128 bytes sent
./bct/nexus_7_grouper_bct.bin sent successfully
downloading bootloader -- load address: 0x80108000 entry point: 0x80108000
sending file: ./bootloader/bootloader-grouper-4.23.img - 2150992/2150992 bytes sent
./bootloader/bootloader-grouper-4.23.img sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
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
Nvflash v1.13.87205 started
[resume mode]
failed executing command 20 NvError 0x120002
Unable to retrieve Partition table from device NvError 0x0
command failure: partition not found in partition table (bad data)
bootloader status: partition table is required for this command (code: 8) message: nverror:0x5 (0x1000005) flags: 0
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.
sudo ./utils/nvflash_v1.13.87205_miniloader_patched --resume --rawdeviceread 0 2048 mmc-0-2048.bin
Nvflash v1.13.87205 started
[resume mode]
failed executing command 31 NvError 0x120002
command failure: readdeviceraw failed (bad data)
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.
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