MacBookPro14,2

Hardware	PCI/USB ID	Working?
Keyboard and touchpad	`APP000D:00`	Yes
Touch Bar	`05ac:8600`	Yes
Touch ID	`05ac:8600`	No
GPU	`8086:5927`	Yes
Audio	`8086:9d71`	Yes
Microphone	`8086:9d71`	Yes
Webcam	`05ac:8600`	Yes
Wi-Fi	`14e4:43ba`	Yes
Bluetooth	UART	Yes
Thunderbolt, USB-C	`8086:15d2`	Yes

This page covers the following Apple models:

MacBookPro14,2 13" 2017 (Touch Bar)

This is the 13-inch 2017 model with a Touch Bar and two Thunderbolt 3 ports. Every device on it can be made to work, but four of them need attention: the Touch Bar and the audio codec need out-of-tree drivers, the Wi-Fi card needs a calibration file before it will use 5 GHz, and suspend needs two sleep hooks. Each section below says which.

The Touch Bar, Touch ID and the webcam are all driven by the T1 coprocessor, which runs its own operating system from firmware stored on Apple's EFI system partition. An installer that reformats that partition erases the firmware and takes all three devices with it, so read #Installation before starting.

The MacBookPro14,3 (15" 2017) shares the T1 and much of this hardware but has not been tested against these notes. The EFI firmware version referenced throughout is 529.140.2.0.0. The T1's own embedded operating system is versioned separately; see #Firmware.

Installation

Follow Mac for the general procedure. Two things are specific to this generation.

Warning The T1 coprocessor's own operating system lives in EFI/APPLE/EMBEDDEDOS on Apple's EFI system partition, alongside a machine-specific FDRData file. An installer that formats or takes over that partition erases it, and the Touch Bar, Touch ID and the webcam stop working: the bridge then enumerates as 05ac:1281 (recovery mode) instead of 05ac:8600. There is no DFU revive for a T1. Back the partition up before installing, and install to free space rather than reformatting the whole disk.

Back up Apple's EFI system partition from macOS before starting, both as files and as an image:

# from macOS, with the EFI partition mounted

tar -C /Volumes/EFI -cf - EFI | gzip -6 > esp-files.tar.gz
dd if=/dev/rdisk0s1 bs=1m | gzip -6 > esp-raw.img.gz

Keep the copy off the machine. It is bound to this machine and is useless on another one. If the folder is later lost, booting the surviving macOS installation is the cheapest recovery, because macOS rebuilds the embedded OS when it finds the folder missing; restoring the backup onto the partition is the other route.

Create the Linux partitions in free space left by shrinking the macOS container, and point the installer at those partitions only. Verify afterwards, before rebooting, that the partition table gained only the new partitions and that the checksum of Apple's EFI system partition is unchanged.

Accessibility

This machine has no text-based firmware setup screen. The only pre-boot interface is Apple's Startup Manager, reached by holding Alt from power-on. It shows one icon per bootable disk with its label underneath and an arrow button below the selected one; on a dual-boot machine that is two, macOS and EFI Boot, the second being whatever bootloader sits on the Linux EFI system partition. Linux is not named. The screen also carries a Choose Network... menu for Internet Recovery. It can be driven with the arrow keys and Enter as well as with the trackpad, so it does not require a pointing device.

The keyboard has no physical Esc key and no physical F1 through F12. Those positions are the Touch Bar, and the Touch Bar is dark throughout the Startup Manager and never lights there, so no function key can be pressed at that screen. This includes Cmd+F5, the shortcut that would otherwise start VoiceOver, which means speech cannot be turned on at the boot picker by any key combination.

Two other routes were tested and also fail: VoiceOver enabled in macOS beforehand does not start at this screen, and a triple-press of Touch ID, which is the Accessibility Shortcut in macOS, does nothing here.

Note Blind users should request the help of a sighted person to select a startup disk.

The screen is legible to a phone camera's text recognition, which reads both labels. The selected entry is marked by a highlight drawn around its icon rather than by any change to its label, so text recognition reveals what the choices are but not which one is currently selected.

Everything in #Installation that happens before that point can be done from macOS, where VoiceOver is available. It is the boot picker specifically that has no speech.

Once Linux is running the Touch Bar can be lit, but it has no tactile edges or detents, so its keys cannot be found by feel at any stage. See #Function keys.

The machine emits the Apple startup chime at power-on, whether or not Alt is held. It is the only sound the firmware produces and it does not encode error states. The startup sound is governed by the SystemAudioVolume Apple NVRAM variable, so another unit can be silent where that has been set to zero, and silence is not by itself evidence of a fault.

The only indicator light on the chassis is the caps lock LED. There is no diagnostic LED and no beep codes, so a failure to start gives a deaf user no visual signal and a blind user nothing beyond the absence of the chime.

Firmware

The firmware is Apple EFI, reported by bootctl as UEFI 2.40 (Apple 1.00). There is no setup utility to enter: everything a PC firmware would expose in a setup screen is either fixed or set from macOS. The EFI firmware version on the machine these notes were taken from is 529.140.2.0.0, dated 2024-06-23.

The T1 coprocessor runs a separate embedded operating system with its own version, 910, recorded in EFI/APPLE/EMBEDDEDOS/version.plist on Apple's EFI system partition. It is not the EFI firmware version and the two move independently.

fwupd has not been tested on this model. Apple delivers both the EFI firmware and the T1's embedded operating system through macOS updates, so a machine left with no macOS installation has no update path for either.

Boot device selection

Hold Alt from power-on to reach the Startup Manager and pick a volume for this boot only. There is no boot-order setting to edit from Linux, so plan on either the Startup Manager or blessing the bootloader from macOS.

Secure Boot

There is none to configure. bootctl reports Secure Boot: disabled (unsupported), no SecureBoot, SetupMode, PK, KEK or db variables exist under /sys/firmware/efi/efivars, and there is no TPM. Secure Boot and the Startup Security Utility belong to the T2 generation, which this is not.

Firmware data path

The EFI system partition is Apple's own and is not a partition Linux should take over. Measured on one machine, it is 300 MB with 34 MB in use, of which EFI/APPLE accounts for 32 MB:

Path	Size	What it is
`EFI/APPLE/EMBEDDEDOS/combined.memboot`	30.7 MB	the T1's operating system image
`EFI/APPLE/EMBEDDEDOS/FDRData`	210 KB	machine-specific, not portable to another unit
`EFI/APPLE/EMBEDDEDOS/version.plist`	360 B	the embedded OS version
`EFI/APPLE/LOG/`	grows	firmware boot logs, see below

The firmware writes its own boot logs to EFI/APPLE/LOG, and they are not small: BOOT-2.LOG was 2.1 MB on the machine measured. Size a bootloader installation against what is left of the partition rather than repartitioning, and do not create a second EFI system partition in the hope of leaving Apple's alone, because the Startup Manager will offer both.

Erasing this partition costs the Touch Bar, Touch ID and the webcam, with no DFU revive on a T1. See the warning in #Installation.

ACPI quirks

The firmware's Thunderbolt power-control methods are gated on flags that only macOS sets, so under Linux its power-off path is never taken and both Alpine Ridge controllers lose power in S3 regardless of what the kernel asks for. This causes the behaviour in #Thunderbolt and USB-C after resume and no kernel parameter overrides it.

Warning The ACPI method \_SB.PCI0.XHC1.RHUB.ASOC.FRST is a hardware reset of the T1. See #The Touch Bar across suspend. Do not evaluate it.

Touch Bar

The T1 presents more than one USB configuration. In configuration 1 it exposes HID interfaces and the Touch Bar shows the firmware's own key strip, which is what the apple-ibridge out-of-tree driver uses. In configuration 2 it exposes a DRM display, a digitizer and a camera, and the host renders the strip itself.

Configuration 1 is the practical choice. Build the apple-ibridge driver set with DKMS, blacklist its modules on the kernel command line so they are not autoloaded during early boot, and load them from a service that runs after multi-user.target; loading them earlier can hang sysinit.target. The modules accept fnmode=1, idle_timeout=-1 and dim_timeout=-1 at load time. The module parameters under /sys/module/apple_ib_tb/parameters/ are read-only and reflect only the value given at load; the writable runtime knob is the per-device node /sys/bus/hid/devices/0003:05AC:8600.0001/fnmode. Note that hid_apple is not involved on this model, so advice written against hid_apple.fnmode does not apply.

Two HID devices appear once the driver binds, and the function-key row works. Touch ID is not usable in this configuration.

Note Configuration 2 gives a host-rendered strip and Touch ID, but does not survive suspend. See #Suspend.

Audio

The Cirrus CS8409/CS42L83 codec needs an out-of-tree driver: snd-hda-macbookpro-dkms-git^AUR or an equivalent build of the same tree. The microphone ships muted; unmute it in the mixer.

Wi-Fi

The BCM43602 works with brcmfmac, but 5 GHz channels are unavailable until the board's calibration file and regulatory domain are set. See Broadcom wireless#BCM43602 802.11ac Wireless LAN SoC. Check the board identifier before choosing a calibration file.

The driver also needs help across suspend; see #Wi-Fi after resume.

Webcam

The FaceTime camera is exposed through the T1 and works with the in-tree uvcvideo driver once the Touch Bar driver has bound, offering MJPG at up to 1280x720. Asking for buffers before setting a format trips a harmless kernel warning in vb2_core_reqbufs; set the format first.

Function keys

This keyboard has no physical function row. The Esc position and F1 through F12 are all rendered on the Touch Bar, so none of them exist until the Touch Bar driver has bound. See #Touch Bar for the driver, and #Accessibility for what that means before boot.

With the apple-ibridge modules loaded at fnmode=1, the strip shows a media row, and holding Fn redraws it as F1 through F12 for as long as the key is held.

Key	Visible?¹	Marked?²	Effect
Touch Bar `Esc`	Yes	Yes³	`Escape`, with or without `Fn`
Touch Bar `F1`	Yes	Yes³	`XF86MonBrightnessDown`, or `F1` with `Fn`
Touch Bar `F2`	Yes	Yes³	`XF86MonBrightnessUp`, or `F2` with `Fn`
Touch Bar `F3`	Yes	No	Nothing without `Fn`, see below. `F3` with `Fn`
Touch Bar `F4`	Yes	No	Nothing without `Fn`, see below. `F4` with `Fn`
Touch Bar `F5`	Yes	Yes³	`XF86KbdBrightnessDown`, or `F5` with `Fn`
Touch Bar `F6`	Yes	Yes³	`XF86KbdBrightnessUp`, or `F6` with `Fn`
Touch Bar `F7`	Yes	Yes³	`XF86AudioPrev`, or `F7` with `Fn`
Touch Bar `F8`	Yes	Yes³	`XF86AudioPlay`, or `F8` with `Fn`
Touch Bar `F9`	Yes	Yes³	`XF86AudioNext`, or `F9` with `Fn`
Touch Bar `F10`	Yes	Yes³	`XF86AudioMute`, or `F10` with `Fn`
Touch Bar `F11`	Yes	Yes³	`XF86AudioLowerVolume`, or `F11` with `Fn`
Touch Bar `F12`	Yes	Yes³	`XF86AudioRaiseVolume`, or `F12` with `Fn`
`Fn+Up`	Yes	No	`Prior`
`Fn+Down`	Yes	No	`Next`
`Fn+Left`	Yes	No	`Home`
`Fn+Right`	Yes	No	`End`
`Fn+Backspace`	Yes	No	`Delete`

The key is visible to wev and similar tools
The physical key has a symbol on it, which describes its function
Drawn on the Touch Bar rather than physically marked, and only while that view is displayed

In the media view the strip draws ten buttons, not twelve. The F3 and F4 positions have no control drawn and emit nothing until Fn is held, even though the HID descriptor advertises two further codes for them.

The function row and the media keys come from the Touch Bar HID device; the Fn combinations come from the SPI keyboard. The ACPI video bus also advertises the brightness codes on this machine but never emits them, so nothing is double-sourced.

Fn itself reaches userspace as an ordinary key event from the SPI keyboard rather than being consumed in firmware, though it carries no X keysym of its own.

Suspend

Suspend to RAM (S3) works and resumes on a keypress. Tested on kernels 7.1.9 and 7.2.3. Two things do not survive it without help: the Broadcom Wi-Fi firmware, and the Thunderbolt controllers with everything behind them, which includes both USB-C ports' SuperSpeed and Thunderbolt paths. The internal keyboard, trackpad, Touch Bar, audio, webcam and display are unaffected, because the T1 sits on the chipset's own xHCI controller rather than on the Thunderbolt tree.

Wi-Fi after resume

On some resumes the chip keeps its PCI registers readable while its firmware has died. brcmfmac then takes its hot-resume path and every command times out, and the link stays down until the driver is reloaded. A systemd-sleep hook that unloads brcmfmac_wcc and brcmfmac on pre and reloads brcmfmac on post makes every resume re-probe and reload the firmware. Expect the association to move to a different access point after the reload on a network with several.

A second failure mode appears only after the short-wake sequences described below. When one lid close produces several suspend and resume cycles in quick succession, the reloaded firmware can refuse every subsequent join, reporting status_code=16 with an all-zero BSSID on each attempt, until the machine is rebooted. That status is the driver's own: brcmf_bss_connect_done() reports any join the firmware fails to complete as WLAN_STATUS_AUTH_TIMEOUT with the profile's BSSID, which is zero when unset. Closes that produce a single clean sleep have not shown it.

Thunderbolt and USB-C after resume

The platform firmware removes power from both Alpine Ridge controllers in S3 whatever the kernel requests. On resume the switch bridges reappear with collapsed windows, the kernel cannot re-assign them at runtime (bridge window ... can't assign; no space), pciehp removes the Thunderbolt-side xHCI controllers, and USB-C is dead until a power cycle.

Kernel-side workarounds do not help. Clearing d3cold_allowed on every device in the tree leaves the ports failing from D3hot instead of D3cold; pcie_port_pm=off and pcie_ports=compat change only what the kernel asks for or owns; forcing the root ports to D0 and rescanning finds nothing, because the link never trains. Evaluating the firmware's own Thunderbolt power methods by hand shows that under Linux its power-off path is never taken, because it is gated on flags only macOS sets, and that the GPIO pads those methods drive read the same on a dead side and a live side. The controllers' power is the platform's to give.

The controllers appear as 8086:1578 and 8086:15d3 bridges above the 8086:15d2 host interfaces. What works is to remove the two Thunderbolt upstream ports before suspend and rescan the PCI bus after resume. The chipset root ports keep their windows, so the rescan re-enumerates the whole tree with fresh assignment. The two Thunderbolt xHCI controllers return on new bus numbers, consistently the same ones on every cycle. Implementations exist in nohzafk/omarchy-macbookpro-t1 and, in a form that discovers the ports from the controllers bound to the thunderbolt driver rather than hardcoding addresses, in omacom/omarchy#11570.

Two limits belong to the platform's sequencing rather than to the hook. A sleep of about a minute or more completes its power cycle and the tree comes back with it; the shortest measured to do so is 51 seconds. A sleep of about 8 seconds or shorter hands back a controller that never finished powering down, and the tree then stays dead until a later sleep long enough to revive it. A reboot is not required. USB-C keeps working at USB 2.0 through the chipset controller while the tree is dead.

Short self-wakes on lid close

Lid-closed sleeps sometimes wake on their own 6 to 8 seconds in and re-suspend a few seconds later. In one controlled session four of eight hands-off lid closes did this once each; the behaviour persists intermittently, including sequences of two and four consecutive short wakes before the machine settles, and including closes with none at all. It matters because each short wake leaves the Thunderbolt tree dead until a later sleep of adequate length, and because repeated firmware reloads are what precede the Wi-Fi failure above.

Every wake source visible to the kernel has been excluded with positive controls: GPE counters, wakeup_sources, PM1 status sampled with an RTC alarm as the control, and the raw GPE0 status and enable blocks. After a self-wake, PM1a status reads zero and the GPE0 status bits are the same inert set seen on held sleeps. The source clears itself before the OS runs and is not nameable from Linux. Attributions that look plausible and are wrong: the SPI topcase, because a close self-woke with its wake disabled; the power button, because the kernel posts a wakeup event on LNXPWRBN:00 for a real one and none appears; the PCIe wake sideband; and the time since the previous close.

An ordinary lid-open wake does leave a signature: GPE 0x6F increments by one. That has held on every lid-open wake observed and on none of the self-wakes, so it is a usable discriminator when reading the evidence afterwards.

The loop appears bounded rather than open-ended: attended closes have run four short cycles before settling into a held sleep. The consequence is that a close spends roughly its first two minutes looping, so a lid-closed test needs three minutes or more to reach a held sleep at all. A two-minute close does not merely fail to measure anything, it is how the Thunderbolt tree gets killed.

The Touch Bar across suspend

The two USB configurations behave differently across S3, which is worth knowing before choosing a Touch Bar stack.

In configuration 1 the strip survives suspend untouched: the kernel logs tb: Touchbar suspended. and tb: Touchbar resumed., the service that loaded the driver does not rerun, and the device does not re-enumerate.

In configuration 2 the panel is dark after every suspend and no host-side action brings it back. Measured over seven lid closes: restoring the firmware's park report to its awake value, toggling the panel-power field, restarting the renderer, restarting the hardware service, cycling the device, re-probing the driver after un-parking, and suspending with the driver unbound so that no park is ever sent. All of them leave the strip dark while the bridge continues to acknowledge frames, so the data path is alive and only the panel's power state is stuck. An independent implementation on a MacBookPro13,3 reached the same conclusion and found that only a fresh configuration-1 probe relights the panel, which does not help after S3. Recovery is a reboot.

Warning The ACPI method \_SB.PCI0.XHC1.RHUB.ASOC.FRST is a hardware reset of the T1. Evaluating it leaves the bridge in recovery mode (05ac:1281), where it stays until the host is rebooted, and that is the same state a machine reaches when its firmware has been erased. Do not evaluate it.

Wake sources

Useful when attributing an unexpected wake, read from this machine's ACPI tables. GPE 0x69: every PCIe root port and the Wi-Fi, on one shared line. 0x6D: the three xHCI controllers and the power button. 0x6F: EC, lid, adapter and Bluetooth, and the line that increments on a lid-open wake. 0x17: the SPI keyboard and trackpad, which ticks by one or two around every suspend and resume and is not a wake signature on its own. 0x32 and 0x33: the two Thunderbolt hot-plug lines, set once per S3 exit. 0x07: the EC's runtime line, which moves by a few hundred on every transition. The RTC fixed event is disabled on this platform, so attribute an alarm wake by wall clock or by RTC_STS in PM1 status.

The GPE0 status bits set at rest are 0x13, 0x31, 0x52 and 0x54, with their enable bits clear and no matching handler in the tables. They are inert and appear in every sample, held and woken alike, so they discriminate nothing.

Reading the journal around a suspend

Kernel lines emitted between PM: suspend entry and ACPI: PM: Waking up from system sleep state S3 carry monotonic timestamps that journald converts after resume, so every pre-sleep line appears stamped with the wake time. Only suspend entry and the lines produced by /sys/power/pm_print_times are real clocks for that window. All per-boot wake counters (/sys/firmware/acpi/interrupts/, power/wakeup_count, /sys/kernel/debug/wakeup_sources, /sys/power/suspend_stats/) are lost at reboot, so dump them before rebooting after an odd resume.