Closed garlandwiersema closed 2 years ago
tofurky
commented
2 years ago 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.
garlandwiersema
commented
2 years ago 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
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$
tofurky
commented
2 years ago it might be an issue with faulty emmc flash. what caused the brick in the first place? see comments here https://github.com/tofurky/tegra30_debrick/issues/5#issuecomment-962387664
garlandwiersema
commented
2 years ago Unaware what caused it to brick, acquired the device in a bricked state.
garlandwiersema
commented
2 years ago 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)
tofurky
commented
2 years ago 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 ;)
garlandwiersema
commented
2 years ago 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.
pgwipeout
commented
2 years ago 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 https://github.com/tofurky/tegra30_debrick/issues/8.
— Reply to this email directly, view it on GitHub https://github.com/tofurky/tegra30_debrick/issues/8#event-5960665554, 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: @.***>
garlandwiersema
commented
2 years ago 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.
tofurky
commented
2 years ago 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 7330command 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 `