Closed tomkcook closed 2 years ago
The only changes in that commit were timing changes (the sleep function calls just wait for that amount of ms). Can you individually adjust those numbers to see which one causes the problem you are seeing?
Gorodn
Checking out ec9155c9784ee9bd91c9179a1fd3d9ca8f963cd3 and reverting changes in main.c back to e89ead9a80e1e45419ce7e54aa2605dbb67d7ee2 doesn't work - the problem must be in either bootcode.bin or start.elf. I'm not sure how to go about debugging these.
So can you take new bootcode.bin/start.elf from the older commit and make the newer commit work?
Why are you working with such an old version of rpiboot?
Can you update to the most recent and try again?
I'm having the same issue here as well. Had 2 Compute Module 3 modules, both using same the same supplied USB cable and power supply. Am able to flash OS onto one, while the other just doesn't work. (Neither Windows nor Linux recognizes it as a MSD). I'm Using the newest rpiboot.
Is it a hardware issue?
Same issue here too. Using the newest rpiboot: managed to flash once, then would never show again as MSD. I try reverting to old version of rpiboot, did not help. I have two cm3 half dead like this. Any lead is appreciated.
Please confirm the following:
CM3 heavy or light? Daughter board you're plugging it into? Compute Module IO Board V2.0 for example? Position of J3, VG0 and VG1 Position of J4, enabled or disabled Linux PC plugged into "USB SLAVE"? Power plugged into "POWER IN"
So when it is powered it just boots into whatever you wrote onto the eMMC originally? I assume you did not try hot-plugging the CM3?
Gordon
Did this ever get resolved? Thanks for the idea to hot-plug the CM3+.
I'm using a Waveshare carrier board called Compute Module IO with PoE. Has issues with W7 upstream PC flashing the 32GB of eMMC, but upon using etcher (after multiple attempts with rpiboot) etcher process seemed to complete without complaint, but no response from CM3+ upon reboot. PHYS LAN port not active, so can't SSH in, and can't config HDMI to get a monitor working, but rainbow square is produced from HDMI output on modern HDTV...the only sign of life.
One odd side effect to report...While etcher was requesting drivers (Etcher recognized the RPi, but didn't see an associated MSD) I had USBDeview open and it registered the following mass storage device (on the very last line in below screenshot...
This seemed to satisfy Etcher:
This definitely isn't the same issue as the OP, but if anyone is having a similar issue with a Pi Zero, you need to do things in this order:
rpiboot
Closing due to inactivity.
I have a pi that isn't put into USB MSD mode by rpiboot. It appears to run successfully, but afterwards no new block devices are present (in fact the pi doesn't show up in lsusb). git bisect shows this being introduced in commit ec9155c9784ee9bd91c9179a1fd3d9ca8f963cd3 ie. with a build from before that commit it works.
This is the output of an rpiboot run which fails:
And this is what dmesg has to say:
I can use the old version for now. I'm happy to help out testing any changes that affect this.