search

raspberrypi / usbboot

Raspberry Pi USB booting code, moved from tools repository
Apache License 2.0
905 stars 229 forks source link

rpiboot doesn't put pi in USB MSD mode #38

Closed tomkcook closed 2 years ago

tomkcook commented 5 years ago

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:

$ sudo ./rpiboot  -v
Waiting for BCM2835/6/7
Found device 1 idVendor=0x03f0 idProduct=0x154a
Found device 2 idVendor=0x04b3 idProduct=0x3025
Found device 3 idVendor=0x8087 idProduct=0x0024
Found device 4 idVendor=0x1d6b idProduct=0x0002
Found device 5 idVendor=0x1d6b idProduct=0x0003
Found device 6 idVendor=0x1d6b idProduct=0x0002
Found device 7 idVendor=0x8087 idProduct=0x0024
Found device 8 idVendor=0x1d6b idProduct=0x0002
... etc ...
Found device 1 idVendor=0x03f0 idProduct=0x154a
Found device 2 idVendor=0x04b3 idProduct=0x3025
Found device 3 idVendor=0x8087 idProduct=0x0024
Found device 4 idVendor=0x1d6b idProduct=0x0002
Found device 5 idVendor=0x1d6b idProduct=0x0003
Found device 6 idVendor=0x1d6b idProduct=0x0002
Found device 7 idVendor=0x8087 idProduct=0x0024
Found device 8 idVendor=0x1d6b idProduct=0x0002
libusb: error [udev_hotplug_event] ignoring udev action bind
Found device 1 idVendor=0x0a5c idProduct=0x2764
Device located successfully
Initialised device correctly
Found serial number 0
Sending bootcode.bin
libusb_bulk_transfer returned 0
Writing 50408 bytes
libusb_bulk_transfer returned 0
Successful read 4 bytes 
Waiting for BCM2835/6/7
Found device 1 idVendor=0x03f0 idProduct=0x154a
Found device 2 idVendor=0x04b3 idProduct=0x3025
Found device 3 idVendor=0x8087 idProduct=0x0024
Found device 4 idVendor=0x1d6b idProduct=0x0002
Found device 5 idVendor=0x1d6b idProduct=0x0003
Found device 6 idVendor=0x1d6b idProduct=0x0002
Found device 7 idVendor=0x8087 idProduct=0x0024
Found device 8 idVendor=0x1d6b idProduct=0x0002
libusb: error [udev_hotplug_event] ignoring udev action bind
Found device 1 idVendor=0x0a5c idProduct=0x2764
Device located successfully
Initialised device correctly
Found serial number 1
Second stage boot server
Received message GetFileSize: autoboot.txt
Cannot open file autoboot.txt
Received message GetFileSize: config.txt
Cannot open file config.txt
Received message GetFileSize: recovery.elf
Cannot open file recovery.elf
Received message GetFileSize: start.elf
File size = 433448 bytes
Received message ReadFile: start.elf
File read: start.elf
libusb_bulk_transfer returned 0
Received message GetFileSize: fixup.dat
Cannot open file fixup.dat
^C

And this is what dmesg has to say:

[  352.568470] usb 1-1.4: new high-speed USB device number 4 using ehci-pci
[  352.676870] usb 1-1.4: config index 0 descriptor too short (expected 55, got 32)
[  352.677244] usb 1-1.4: New USB device found, idVendor=0a5c, idProduct=2764
[  352.677249] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  352.677252] usb 1-1.4: Product: BCM2710 Boot
[  352.677255] usb 1-1.4: Manufacturer: Broadcom
[  354.473346] usb 1-1.4: USB disconnect, device number 4
[  354.696477] usb 1-1.4: new high-speed USB device number 5 using ehci-pci
[  355.320478] usb 1-1.4: device descriptor read/64, error -71
[  355.537328] usb 1-1.4: New USB device found, idVendor=0a5c, idProduct=2764
[  355.537334] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=1
[  355.537337] usb 1-1.4: Product: BCM2710 Boot
[  355.537340] usb 1-1.4: Manufacturer: Broadcom
[  355.537343] usb 1-1.4: SerialNumber: Broadcom
[  356.265248] usb 1-1.4: USB disconnect, device number 5

I can use the old version for now. I'm happy to help out testing any changes that affect this.

ghollingworth commented 5 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

tomkcook commented 5 years ago

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.

ghollingworth commented 5 years ago

So can you take new bootcode.bin/start.elf from the older commit and make the newer commit work?

ghollingworth commented 5 years ago

Why are you working with such an old version of rpiboot?

Can you update to the most recent and try again?

huyuanrong commented 5 years ago

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?

emms007 commented 5 years ago

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.

ghollingworth commented 5 years ago

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

ESandM-Public commented 4 years ago

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... image This seemed to satisfy Etcher:

image

leo60228 commented 3 years ago

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:

  1. Connect Pi Zero to computer
  2. Wait for it to show up
  3. Insert SD card
  4. Run rpiboot
timg236 commented 2 years ago

Closing due to inactivity.