Apple's MacBook Pro DFU port documentation is wrong

Posted by zdw 5 days ago

Apple's MacBook Pro DFU port documentation is wrong(lapcatsoftware.com)

199 points | 75 commentspage 2

thenthenthen 4 days ago|

All documentation is wrong, well, nearly all!

KurSix 4 days ago||

This feels like a perfect example of Apple's modern "it just works… until it very much doesn't"

executerh 5 days ago||

[dead]

dangus 4 days ago||

[flagged]

lapcat 4 days ago|

> To the article of this piece: are you enlightened yet?

> Have you decided yet to stop buying Apple hardware?

I'm a professional developer of Mac and iOS software, so I'm enlightened enough to just complain on my blog and then go about my business of making money, rather than throwing away my entire livelihood, especially in this economy.

dangus 4 days ago||

That’s totally fine, but most people are not professional Mac and iOS developers, and most people who are have a company issued laptop.

My iOS apps are developed entirely on a Linux system leveraging cross platform frameworks, and App Store Connect is entirely web based. My build system is cloud based, I have never touched Xcode (one of the worst IDEs out there, with a rating below 4 stars on the App Store).

sneak 5 days ago||

> By the way, Software Update in System Settings allowed my Mac to go to sleep during the “Preparing” phase, despite the fact that the battery was charged to 99%, so when I returned home from a workout I unhappily found 30 minutes remaining. Sigh. Whatever happened to “it just works”?

All the people that were fanatically dedicated to the concept of not shipping user-hostile software retired or got laid off or quit.

The state of care and level of user compassion in modern macOS is at the nadir.

recursive 4 days ago||

Apple's been shipping user-hostile software for decades. I quit after they closed the gap in the wall that allowed me to add a song to my ipod without going through the monstrosity called iTunes.

relaxing 4 days ago||

I’d like to know more about that! Why did they quit? Who replaced them?

sneak 4 days ago||

The corporate culture shifted steadily at Apple following Jobs’ death. It was obviously a turning point for the company and while the change wasn’t overnight, in the ten years that followed, a lot of people moved on, because (obviously) Apple will never be Apple under Jobs ever again.

Because many of them had been with the company a long time (and were thus old), they were replaced by mostly younger people who had less experience with what makes Apple Apple.

In my personal opinion, the soul went out of the company. It wasn’t immediately when Jobs died - to his credit it took more than a decade for the momentum of his vision to die.

Today, Apple is just another multinational, nickel and diming their customer base for services revenue, cooperating with the totalitarian surveillance state (not that they have much choice in the police states of the PRC and USA in which they operate/can’t fight city hall), shipping incrementially improved products (and incrementally worse software), and misleading their customers with clever marketing. It’s just business. It used to be something else entirely.

vlovich123 5 days ago|

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.

comex 5 days ago|

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

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

youarentrightjr 5 days ago||

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

DannyBee 4 days ago|||

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.

youarentrightjr 4 days ago|||

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

vlovich123 4 days ago||||

Then why is there only one port capable of DFU?

tpmoney 4 days ago|||

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"?

youarentrightjr 4 days ago|||

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