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
The source the author is referring to, Michael Tsai, indeed found that he had plugged his external disk into the DFU port. The author then (reasonably, but IMHO erroneously) deduced that his problem, also solved by changing ports, must thus have had the same cause. I say it may be confounding factors, and the only way to validate the wrong DFU port hypothesis is putting their mac in DFU mode and then running Recovery Assistant (from another machine) against it, on various ports.
Tangentially, it is infuriating that Apple would swap what the DFU port is across generations, as if it wasn't confusing enough.
Also...
> As for reasons, I don't know why anything that can boot from USB can't from DFU-enabled USB port, but maybe it's configured as a special non-USB debug connector while bootloader is executing.
My guess is it's because DFU requires the port to be in Device mode, whereas booting from a external disk requires the port to be in Host mode. Apple care about boot time, so perhaps they don't want to waste time in the boot process to check the port in Device mode for a few secs, then switch to Host mode to try external disk booting.
I'd rather not. I'm not even sure that I have all the prequisitives on hand.
> I'm not sure why they're blaming the DFU port documentation.
1) The documentation says that macOS cannot be updated on the DFU port.
2) Switching ports allowed my macOS update to succeed after repeated failures on one port.
3) The 14-inch MacBook Pro with M4 chip is documented as different from all other models, but strangely, not the 16-inch MacBook Pro with M4 chip.
You don't present any alternative theory for the behavior, just assert that I'm wrong.
He is saying the documented _behaviour_ of DFU port is wrong (or, at least, in complete.)
> This is wrong, a discovery that took me about a half dozen attempts to update macOS on an external disk. I have a 16-inch MacBook Pro with an M4 chip, specifically an M4 Pro chip, and the DFU port seems to be the USB-C port on the right side of the Mac, not on the left side."
It appears that the author is directly contradicting your read.
UPDATE: nevermind--removed a paragraph as it does not appear the root cause is which port is DFU, but a misunderstanding of the DFU process by the blogpost.
[1]: at least once per every iOS/macOS device I have purchased to protect against software supply chain attacks when you receive a laptop in mail. DFU-restoring Apple software ensures that the OS you run is not tampered with as long as there is no bootrom exploit or hardware modification.
The DFU port is definitely not the singular one on the right side of the device. The documentation debate is about which port on the left side of the device (closer or farther from MagSafe.)
I think the short, single clause, internal-monologue-ish sentences is what did it?
> I am reading the post again. It does appear the author is not fully aware what DFU is supposed to do.
That especially came off like an LLM being called out on being wrong about something?
Coming back to the author's story, as others have pointed out as well, I do not think it is related to the DFU port itself. I think it depends on the BIOS/UEFI firmware which is addressing those ports, and then the bootloader who is responsible for finding the system (root) volume.
Nowadays these happen with Volume UUIDs hence it should not matter, at least in theory. But even GRUB adds a hint, as discovery just with UUID may fail.
Since we cannot see what actually is happening or see the logs, I would simply say: "Always use the same port for booting and installation." Which usually simplifies the process.
I am quite certain "the undocumented DFU port" was the port author initially used to install macOS to the external drive. Maybe on another Mac/machine. When they change the machine, addressing/enumeration of ports may be different, due to how boot process works. Therefore, let's say you used the port=0x3 in the first install, when you change the machine, you need to find the same port=0x3. Thus being the undocumented-DFU-port author mentions.
> P.S: Also DFU port is for installing firmware (BIOS/UEFI) to the device even before boot occurs. For example, you should connect one end of a USB cable to a working computer (ie. "master"), another end to the DFU port of target (ie. "slave") while the machine that is off. Some specific sequence of power-key combination puts target machine into DFU-mode, where you can overwrite the firmware (UEFI/BIOS, etc) from the working machine... That is the purpose of DFU. -- Or at least access the internal hard-drive/SSD without actually booting the "slave" machine.
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.
> [1] https://asahilinux.org/docs/hw/soc/usb-pd/
What in your linked page made you conclude this? Your link references https://web.archive.org/web/20211023034503/https://blog.t801..., which clearly states that ACE is a port controller - this is not the same as a "USB controller".