search

bishopdynamics / superbird-tool

Cross-Platform Spotify Car Thing (superbird) hacking toolkit
133 stars 8 forks source link

(windows) getting "bulkcmd timed out!" what should i do? #10

Open hassidan opened 1 year ago

hassidan commented 1 year ago

when trying to do anything except entering burn mode and finding device, i get "bulkcmd timed out!" here is the output:

PS C:\Users\****\******\superbird-tool-main> python superbird_tool.py --boot_adb_kernel a
Spotify Car Thing (superbird) toolkit, v0.0.8, by bishopdynamics
     https://github.com/bishopdynamics/superbird-tool

Found device booted in USB Burn Mode (ready for commands)
Booting adb kernel on slot a
Booting images/env_a.txt, images/superbird.kernel.img, images/superbird.initrd.img
initializing env subsystem
 executing bulkcmd: "amlmmc env"
 Error: bulkcmd timed out!
 This can happen if the device ends up in a strange state, like as the result of a previously failed command
 Try power cycling the device by pulling the cable, and then boot up and try again
  You might need to do this multiple times
    If the device is connected through a USB hub, try connecting it directly to a port on your machine
williamtcastro commented 1 year ago

sometimes it happens with macOS too, I just keep trying until it works.

bishopdynamics commented 1 year ago

I found that i had the most success when using a port directly on my machine, without any extension cables or hubs in between.

spartan64 commented 1 year ago

@bishopdynamics I have the same/similar issue on Windows. I’m getting a “bulkcmd timed out” error while attempting to “restore_device” it sounds like a few people have run into this too on the Discord. Any recommendations? I think most people followed your instructions

leolion3 commented 2 months ago

Edit: Fix available in #18

Its actually much simpler than that - I had the same problem and dug into the code. Its attempting to restore one of the files at the wrong offset. The bug is not in restoring system_b.ext4 - this is a simple logging error, but rather in restoring the data file which comes after it.

It you delete data.ext4 and restore without it everything works as it should The reason this doesnt matter - as is obvious from the code, but isnt documented anywhere - is that the data file gets rewritten on first boot anyway if it does not exist in the dump (as would be the case from a factory-fresh device). Thus the file can be safely deleted This is the problem. Deleting the data.ext4 and performing the restore without it works perfectly