search

raspberrypi / usbboot

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

When using an USB-C → USB-C cable, the device doesn't come back for the 2nd stage on some devices. #158

Closed WeeJeWel closed 1 year ago

WeeJeWel commented 2 years ago

This is a quite interesting but weird problem, which I'm frankly unsure of whether it's fixable by usbboot at all.

A CM4 on a carrier board with an USB-C connector, regardless using USB-C PD or not, always shows up as BCM2711 Boot when connected and nRPIBOOT is enabled. So far, so good.

Then usbboot runs and uploads the fileserver bootcode. The BCM2711 Boot disconnects. So far, so good.

On some devices, BCM2711 Boot comes back with a fileserver. All is good! On other devices, e.g. all MacBooks that I've tested, the CM4 doesn't come back again.

Now here's where the fun starts. When using an USB-C (CM4) → USB-A (MacBook) cable on the same MacBook, everything works fine!

I think this has to to with the USB-C PD (CC) protocol, but honestly, I don't even know where to start looking.

Any clue?

timg236 commented 2 years ago

There is a USB soft-disconnect when switching between the ROM file-loader and the file-server. I't possible that that host doesn't like that but you'd need a USB analyzer to debug further e.g. to see if the Pi is doing something that's not compliant with the USB spec. Unfortunately, I don't think anyone here is going to be able to spend time investigating non-Linux OS ports / different cables etc

WeeJeWel commented 2 years ago

Thanks for the reply! I didn't know a soft-disconnect was a thing, so that's already helpful. To be continued...

timg236 commented 2 years ago

IIRC it puts the PHY into a mode where it ignores all packets so it should look like a physical disconnect to the host.

WeeJeWel commented 2 years ago

Update: sometimes it does work as expected.

ghollingworth commented 2 years ago

It will be due to the quality of the cable, we've seen before USB cables with an impedance double (or half) of the 90ohm specification. This then causes problems with the USB signals which sometimes work and sometimes don't (it really depends on the quality of the USB cable). Good quality cables tend to work fine, others may or may not work. The fact it works when you add another thing may just again be a bit more randomness added to the signal integrity...

WeeJeWel commented 2 years ago

Hm... but when using the same USB-C cable, but with a small USB-C → USB-A adapter at the end, the problem never occurs.

ghollingworth commented 2 years ago

You're just adding more impedance, exactly what the effect will be can only really be determined by some very expensive test equipment and a bunch of smith charts. I can't be sure that is the problem in this case, but it has been seen in the past (with cheap cables) which produced a similar failure.

WeeJeWel commented 1 year ago

@timg236 I've thought about this, and because it sometimes works, I think it's a timing issue. Can we add some delay in the bootcode between the usb device disconnect and reconnect? As if the 'cable' was plugged out longer.

timg236 commented 1 year ago

Please can you check the latest version. It does a soft disconnect when the second stage is initialised so you should see a delay whilst SDRAM is initialised.

WeeJeWel commented 1 year ago

omg it works! Thank you so much!! <3