Stuck in loop - Failed control transfer (-7,24) #87
Comments
|
I just tried flashing again with another CM4 & the same IO board and it works as it should. The faulty CM4 has already an OS installed which boots if the jumper is removed, so I think this is some sort of software issue. Do you have any solution for this problem? |
|
I'm trying the rpiboot for Rpi CM3 module. I see similar errors: with and with |
|
Is there any progress on this issue, as this seems to affect multiple people and potentially bricks CM4s? |
|
Hey @ddibiasi, I have gone throw many issues like these(eg- EMMC/SD Card MSD Mouting), And I have seen 2 common solutions to all of that issues. Which are A good USB cable and A Decent Power supply. Both can solve these types of problems on many Raspberry pi hardware platforms. |
|
I had this issue, but it was on a fresh Compute Module 4. |
|
This issue still exists despite having tried multiple different USB cables, as well as power supplies, as mentioned by @Sagar73594 . I also have tried usbboot on multiple different PCs, using different operating systems (Linux, Windows) to no avail, as suggested by @scott-williams-xentronics . As this was last tried in August, there could potentially have been a fix in the GitHub repo, so I'll need to retry usbboot with the said bricked device. |
|
I'm also running into this. I tried several cables, ports, hubs and no hubs in between, several CM4s and two different IO boards. The problem persists. Using a USB protocol analyzer I see nothing of significance (but I am not an expert on this at all). However I just plugged the exact same IO board + CM4 + cable to a different computer - and there it works. The notebook where it's not working is an DELL XPS and the XHCI controller is named
according to https://pci-ids.ucw.cz/read/PC/8086/43ed The PC where it works lists the respective USB host controller as
Probably not something anybody here could do anything about, but OTOH maybe a puzzle piece to understand the issue better. |
|
Super interesting. I wonder if there's any action we can take? |
|
I have some new information in the meantime. While it appeared to work (meaning the rpiboot was actually doing what it's supposed to do), mounting and working with the block device is fraught with errors. It produces fun error messages, see below. Using a newer Dell XPS of a colleague with USB host controllers identifying as "something something Thunderbolt 4" (sorry, I just read the output of lsusb and recite from memory) actually did work for rpiboot, but again mounting would fail. This whole thing is driving me nuts. Edit The below error messages seem to be disappearing when using a better power-supply. I might have gotten sloppy there. However the exact same power supply was used for the original Dell XPS. |
|
The recommended setup for the usbboot host is
libusb on Windows seems to be a bit flakey and doesn't always discover devices behind hubs. Since there's an infinite variety of device OS/USB configurations we only test with the above (we use that for manufacturing so it's well tested) |
|
Thank you for the clarification. And a good idea for a workaround if I can't get my Linux XHCI controllers to behave :) |
|
Ok I tried this - PI3, CM4 IO Board, latest Pi Os, cloned & buillt rpiboot on the system, and got essentially the same result I see everywhere else. See dmesg output below. My interpretation here is that the writing is stuck somehow and the kernel worker queues responsible start complaining if the tasks they were given aren't finished. I tested this for now just with one setup. However I did test several CM4 modules, SD-cards and cables with the same results, albeit with a PC host. I can conduct the same tests with the PI3, but am at this point a bit skeptical about it yielding different resutlts. |
|
I think the callstack indicates that the a write command never completed so the kernel timed out and killed the process. How are you writing the image to the Compute Module e.g .imager or are you just accessing files directly? |
|
I've been using dd to flash the whole image in this case, but also observed problems in the past when mounting and accessing, especially again writing. |
|
A quick follow-up: it appears the SD-card-brand makes a difference. I got eMMC CMs today, and with them I was able to flash. I then used a SanDISK SD-card in the IO board + CM4 that was failing before, and have flashed 20 or so times in a row, no problem. Back to the NetAC-card I used, and I get sporadic failures. The speed seems to have degraded between CM3 and CM4, it used to be between 5-6MB/s, now it's about 3.5-4, 4.7 with eMMC. Is there a chance of increasing compatibility or speed? |
|
I have/had a similar problem here. With one PC (Windows 64 bit, Dell, company notebook), Used the same CM4, on same self built baseboard, same USB cable on a different notebook Afterwards I tried a mix: Start rpiboot on old PC, when new disk windows opened, disconnected the USB and connect it to new machine. From there also new disk windowed opened and I was able to flash the complete image without an error to a SD card. |
|
@ddibiasi Please could you retry with the latest version. Over the last few months there's been some improvements to how the USB control is inherited from the ROM so it would be useful to know if that helps. N.B. The recommended host is Raspberry Pi or Linux PC without a hub between the Compute Module and the host. |
|
I have this same problem on an M1 MacBook Pro. I can not get rpiboot to work. Found candidate Compute Module...Loading embedded: bootcode4.bin |
|
I'm running into the same issue. I received a new batch of 10 CM4's that are all experiencing this issue. I've compared these units with working ones and noticed some visual differences between them. I've included a picture of the two below. I've marked some differences on the unit that's having this issue. This seems to be the newer device.
Edit |
Great finding. This was also the case for me - I was just a second to giving up on this CM4 and then saw your edit. Balena Etcher seemed to block a correct connection as well. I had to reattach the USB cable to my mac, rerun |
|
Yep, I also found that I had to update rpiboot to a newer version in order to handle the newer CM4 hardware I received. And unfortunately, you cannot run rpiboot and balenaEtcher simultaneously. You have to do rpiboot first, then bE. Hopefully they'll fix this detection issue soon... I get the sense that a lot of folks were forced to the CM4 due to the CM3+ supply issues. Manufacturing is a complete cluster at the moment. |
|
New devices have been sent to balena for verification of use with etcher, however, I've not had confirmation from them that it has yet been done, although it was a while ago. I'll email them again to see if there have been any progress. |
|
The new CM4s report identical USB descriptors and the SoC is the same, there are no differences in the the USB interface. All that's required is to have a new enough version of rpiboot so that it loads firmware supporting the new PMIC. The significant difference is not circled in the photos. See bottom left, the MXL power supply has been replaced with a Dialog part. |
|
@timg236 |
|
The latest version of rpiboot supports both but I think it's been supported for well over a year now. The Product Information Portal is the place to go for product update information |
|
Please email [email protected] to request parts for testing, please give as much information as possible on your use case, so our commercial team can make the appropriate decisions on supply. However, there is no guarantee parts are available at this time. |
|
https://pip.raspberrypi.com/categories/645/documents/RP-001606-PC/RP-001606-PC-2.pdf " |
Are you reporting this as an error in the PCN? Or just reporting it? |
|
"Are you reporting this as an error in the PCN? Or just reporting it?" Just for info, that above info can be found in an official document |
|
I had this problem as well with a CM4 on the official IO-Board. Dialing it down to 12V exactly, fixed the problem for me. Might be worth a try for other people using variable power supplies. |
|
Had the same issue on a M2 Mac mini. Swapping USB cables worked. |
I had the same error, reinstalling the "rpiboot" worked for me. |
|
I get the same loop when running the |
Hello,
I'm trying to flash the CM4 on the official IO board.
The jumper has been set to 'Fit jumper to disable eMMC Boot' and I am using the latest usbboot.
If i try to run
sudo ./rpibootit gets stuck in this loop:This issue is probably related to #82.
Output of
sudo ./rpiboot -vvThe text was updated successfully, but these errors were encountered: