I’m curious if anyone knows the reason it’s so strict about the port? It’s a weird thing. My best theory is maybe in DFU mode it skips HAL enumeration and just has a hardcoded link between that single port and the microcontroller that does DFU? It’s a stretch but that’s the main theory I have and would explain why they also sometimes had weird capability mismatches between ports on different sides.

Edit: according to ChatGPT that is basically the reason. That one port is connected to the SoC’s building PHY that’s guaranteed to be on without needing any firmware. Other ports are routed through other controllers and whatnot and those may require firmware. Also the DFU port is guaranteed to not need PD negotiation to turn on.

DFU could opportunistically try to load firmware and start those devices but it’s risky since the firmware may be what’s bricked and might itself break DFU so for simplicity it’s in an absolutely barebones mode that the CPU supports and is wired for directly.

The author did not test the DFU flow, so I'm not sure why they're blaming the DFU port documentation.

Certainly there is a bug in the external disk upgrade sequence if switching the disk to a different (also non-DFU? They didn't specify) port solved their problem. But that's not necessarily related to which port is the DFU port.

To be clear, DFU (Device Firmware Upgrade) is a standard USB protocol (from 2004!), for a device to receive upgrades from a host. It is a specific port on the mac because that's all the boot-rom can support. This system does not come into play when booting from or upgrading an external disk, as the author was struggling with, because the external disk cannot be a USB Host to drive the DFU.

And I'm guessing that the reason macOS doesn't give more details is because macOS is likely not involved in the step that fails (maybe iBoot is?), and they didn't develop a way for the failing step to communicate failure data back to macOS. Yet another UX failure.

  Situation:
  - The author is running macOS ARM64  
  - off of a USB disk  
      - plugged into DFU capable USB-C port    
      - that shouldn't be the DFU one according to docs
  - attempting to run macOS updater  
  - (supposedly)there's nothing else connected to it  

  Outcomes:  
  - updates were failing and rolling back with cryptic errors  
  - errors persist despite all efforts  
  - -> later magically solved after changing the port  
  - -> the problematic port later revealed to be the DFU port  
      - contradictory to Apple documentation

          - plugged into DFU capable USB-C port