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 and a patch to the audio driver. 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. t1-revive reports regenerating the folder from Linux, without macOS, on all four T1 models. That recovery has not been tested on this machine.

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.

The firmware also deletes those logs on its own. On the first power-on after six days in which neither macOS nor Linux had booted, both BOOT-*.LOG files were gone while the EMBEDDEDOS files stayed byte-identical. A checksum of the whole partition can therefore change with nothing damaged, so when one changes, compare the EMBEDDEDOS files before concluding anything.

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 may come up muted, as reported on another unit, though it did not on the one measured, so check the mixer before suspecting the driver. The driver also needs a patch to survive suspend. See #Audio after resume.

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, and on 7.2.5, 7.2.8 and 7.2.15 as Omarchy's linux-omarchy build. Three things do not survive it without help: the Broadcom Wi-Fi chip, the audio codec, and the Thunderbolt controllers with everything behind them, which includes both USB-C ports' SuperSpeed and Thunderbolt paths. The internal keyboard, trackpad, Touch Bar, 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 costs 5 GHz only. A sleep that cuts the chip's power resets its ChipCommon chipcontrol register, which clears bit 4, the discrete FEM control pin mode. Only the platform firmware sets that bit, at boot: the register reads 0x01400090 on a fresh boot here and 0x00000000 after such a sleep. Without the bit every 5 GHz join fails, reported as status_code=16 with an all-zero BSSID, while 2.4 GHz still works, and reloading the driver does not help. 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, so it does not name the cause. Short sleeps usually cut the power and sleeps of minutes have not, but one 2.6-second sleep kept it, so length alone does not decide.

Setting the bit again with brcmfmac unbound, then loading the driver, restores 5 GHz on the same boot. A kernel patch that does this in the driver for this model, the MacBookPro13,3 and the MacBookPro14,3 is on linux-wireless and is not in kernel 7.2.15. Until it lands, the post-resume hook can set the bit from userspace before it reloads the driver.

Audio after resume

After every deep S3 the speakers and the internal microphone are silent until a reboot, while the software side looks healthy: the stream is running, the sink is unmuted and the speaker port is active. The codec has lost its programming. /proc/asound/card0/codec#0 shows all eight GPIOs at enable=0 dir=0 data=0, where a fresh boot shows mask 0x0f. The out-of-tree driver's resume path re-syncs only its cached registers, and the setup that programs the GPIOs, the amplifiers and the CS42L83 runs only at probe.

Pull request 220 to the driver fixes this. When the codec comes back blank it programs it again, and logs one cs8409: the codec came back without its setup, programming it again line per resume. With it, the speakers and the microphone worked after a long sleep on kernel 7.2.8, and on 7.2.15 the line appeared on nine of nine resumes and the speakers worked after the one checked. Until it is merged, apply it to the driver's source tree before the DKMS build. DKMS rebuilds from that tree on each kernel update, so the patch carries over, but reinstalling the driver from fresh source drops 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. Re-checked on 7.2.15 after two short sleeps: with both root ports held at power/control=on for several seconds, minutes after the wake, the links stayed at Width x0 with DLActive-, and a rescan found nothing. 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.

On 7.2.15 each of two lid closes self-woke twice, after 2.8 to 4 seconds each, before holding. Sleeps entered with the lid open, such as an RTC-timed test suspend, often end within 4 seconds on 7.2.8 and later: 11 of 11 on one 7.2.8 boot and 2 of 2 on 7.2.15, though one 7.2.8 boot held for 118 seconds. Close the lid for any test that needs a long sleep.

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 none of the host-side actions tried here 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. Work on other models continues in t1bridge issue 18: a write of the awake value relights the strip after s2idle, and calling the ACPI method SOCW(1) after an S3 resume relit it on a MacBookPro13,3 running a different Touch Bar driver. Neither has been tested here.

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.

Hibernation

Hibernation works with the swap file and resume= parameters that Omarchy's installer sets up. The swap file sits inside the LUKS volume, so every resume asks for the passphrase first. Tested on linux-omarchy 7.2.15 over three cycles with the lid open. It needs two changes.

The default ACPI S4 mode (HibernateMode=platform) wakes the machine straight back up with the lid open. The image is restored and the session comes back, but the machine does not stay off, and on that restore a Thunderbolt xHCI controller dropped and was re-added with a kernel warning. The only S4 wake sources enabled in /proc/acpi/wakeup are the Wi-Fi card (ARPT) and the lid (LID0), and which of them fires was not identified. A plain power-off avoids the problem:

/etc/systemd/sleep.conf.d/hibernate-shutdown.conf

[Sleep]
HibernateMode=shutdown

With it the machine stayed off until the power button was pressed, in two of two tests, and the restore brought back the session, both Thunderbolt sides, Wi-Fi on 5 GHz and, with the patch from #Audio after resume, sound. The Thunderbolt problems described under #Suspend do not appear, since the power-off resets the tree.

The T1 sometimes restarts during the power-off (in one of the two tests). It then re-enumerates on the restore, and the generic hid-sensor-hub driver claims the iBridge HID interface that carries the Touch Bar reports, as it also does at boot on this machine, so the strip stays dark. Moving the interface back to apple-ibridge-hid relights it. Write the device name (for example 0003:05AC:8600.0004) to /sys/bus/hid/drivers/hid-sensor-hub/unbind and then to /sys/bus/hid/drivers/apple-ibridge-hid/bind, then set fnmode, idle_timeout and dim_timeout again on the device that has them. Rebinding the apple-ib-tb platform driver does not help. Reloading apple_ibridge is best avoided, because its probe evaluates the T1's SOCW method on a running machine. A hook in /usr/lib/systemd/system-sleep/ can make the move after any wake that leaves the Touch Bar controls missing.

Tip With hibernation working, UPower's critical battery action can hibernate instead of powering off. The default CriticalPowerAction=Auto resolves to suspend-then-hibernate, which never reaches the hibernate step on this machine because lid-open sleeps end after a few seconds. Set CriticalPowerAction=Hibernate in a file under /etc/UPower/UPower.conf.d/ and restart upower.service. The critical action itself has not been exercised.