Comment by vlovich123 | Hacker News Reader

Comment by vlovich123 | Hacker News Reader

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.

ChatGPT is wrong. The DFU port does go through a USB controller with firmware. [1]

[1] https://asahilinux.org/docs/hw/soc/usb-pd/

> ChatGPT is wrong. The DFU port does go through a USB controller with firmware. [1]

> [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".

Doesn't that linked webarchive page say specifically that the ACE is a "Apple/TI co-designed USB Type-C Port Controller"

If that isn't a "USB Controller" what do you mean when you say "USB Controller"?

> Doesn't that linked webarchive page say specifically that the ACE is a "Apple/TI co-designed USB Type-C Port Controller" If that isn't a "USB Controller" what do you mean when you say "USB Controller"? "USB controller" in common parlance means a USB host controller, the hardware that actually controls the USB signals and interfaces with the host CPU(s). They are required no matter if the physical port is type A, B, C, ... A "port controller" is something completely different, but still related to the "USB type C port" specification. It's a piece of logic (in this case in a separate IC) that handles things like negotiating PD, as well as which protocol(s) will be used over the high speed lanes etc. See the section about pin usage in different modes: https://en.wikipedia.org/wiki/USB-C comex's comment is inaccurate with respect to the commonly understood meaning of "USB controller" - while that port does have the CC lines going to ACE, the actual USB data lines go to the Apple SoC directly. This is contrasted with a different design where the USB data lines could go to a standalone IC, and that IC is connected to the Apple SoC via PCIe for example. DFU is significantly more complicated in this type of design because it requires bootstrapping and interaction with this external component.

I may be able to resolve this, having hacked a bunch on M1N1 and such - the DFU port is going through a microcontroller with firmware.

That is why, for example, it can properly process USB-PD messages that contain vendor defined message codes, even prior to any form of boot, as long as it has any source of power.

The firmware on the USB controller is processing that.

This is how VDMTool works to be able to mux debug (and do other things) even with the machine otherwise off.

See my response to tpmoney - not all signals in the DFU port go to the port controller.

Then why is there only one port capable of DFU?

Reply on news.ycombinator.com