DFU Mode Restore (Macs)
Only on T2 Macs!
- 2018+ A1989/A2159 13" MacBook Pro
- 2018+ A1990 15" MacBook Pro
- 2019 A2141 16" MacBook Pro
- 2018+ A1932 13" MacBook Air
- 2018+ A1993 Mac mini
- 2017 A1862 iMac Pro
- 2019 A1991 Mac Pro
- 2020 A2338 13" M1 MacBook Pro
- 2020 A2337 13" M1 MacBook Air
- 2020 A2348 M1 Mac mini
Scenarios for restore:
DFU mode is needed (rarely) to restore the T2 firmware when:
- Failed macOS upgrade/reinstall/Security Update
- Failed Combo or Delta update
- Unable to boot into the current OS Internet Recovery using command + option + R
- Unable to successfully create computer account and log in after erasing and reinstalling (M1 computers specifically)
Other reasons to restore:
Essentially anytime you see something that communicates with T2 not function, a DFU restore may resolve. However, rule out other possibilities first!
A few examples:
- Battery communication lines being pulled down - but not short causing battery not being recognized and not charging. T2 handles SMC communications now.
- Raise/Wake not working properly. I've had two scenarios:
- 1: LID_OPEN_LEFT, LID_OPEN_RIGHT, and IPD_LID_OPEN would all function properly when triggered, however the unit would not sleep when lid closed. DFU restore fixed
- 2: (820-01958) SMC_LID_RIGHT was low - 1v1 instead of the 1v8 it should be. Causing the unit not to fully wake when raising the lid (did respond when lid was closed) The camera also did not work, which lead me to U4850. I replaced U4580, which fixed the camera, however the SMC_LID_RIGHT line was brought even lower to .110v I isolated the issue to T2. I attempted a restore, this did not work. I tied IPD_LID_OPEN to SMC_LID_RIGHT to put a bandaid on the situation. Obviously this way the unit won't functional properly.
The moral of the story here, is before you attempt a DFU restore, for something that could be T2, attempt to rule out everything else before the restore, as you could brick the unit, and be in a worse condition.
Beware of the risk!
Rule out parts or any other board issue that is possible before DFU restoring the unit. There are many things that can cause a DFU restore to fail. The problem is, if you fail a DFU restore, you may end up in a different error state than your original issue. For example:
If you have a board that comes in, with no power. You plug it into another unit, to check if its in DFU mode. It's not. Let's say PP3v3_G3H is shorted. Let's call this Failure State A.
Now you're in Failure State A, and you decided to force the unit into DFU, and attempt a restore. At this point, it would fail, and you would be stuck in recovery, let's call this Failure State B. Now you're at Failure State B, it makes it 10x harder to diagnose Failure State A, simply because you can't follow the power structure anymore. At this point, if you find you're short on PP3v3_G3H and remove it, you would have to restore again and PRAY that it works. It does not always. There have been many cases, where the unit came in with liquid damage, clearly a Failure State A type of situation, but the client attempted to restore before sending it, making it into a Failure State B. It seems half the time, after I fix Failure A, that I am able to get out of Failure B after restore. The half that is unsuccessful, is, I'm sure because of a damaged trace or something like that - however, with it being in recovery, or Failure State B, it's much harder to diagnose.
DO NOT DFU IF TARGET MAC IS ON BETA SOFTWARE. THIS WILL BRICK THE MAC AND YOU WILL HAVE TO DO THE WALK OF SHAME TO AN APPLE STORE.
You will need:
- a host Mac which has minimum OS of 10.13.5, Apple Configurator 2.6 or newer installed (from App Store), and an internet connection.
- USB-C cable which supports data, USB A to C cable, or Thunderbolt 3 cable.
- Target Mac (one that is being put in DFU) is connected to power. Do not use the left port closest to track pad for power - you will need this for data.
Make sure Host Mac is powered up, iTunes is not open if applicable (fully quit) and open Apple Configurator 2.
For Intel MacBook Pro and MacBook Air - Make sure Mac is shut down (hold power button for 5 seconds). Plug in data cable to Host Mac (any port) then into the left port closest to track pad in the Target Mac. Hold right shift + left option + left control + power keys simultaneously for about 3 seconds (according to Apple, other sources say 4-8 seconds). NOTE: We found that if you press the power button for 1 one thousand and then simultaneously hold the right shift + left option + left control, you should be successful each time. We also found that we were able to get in DFU mode around 4 to 6 (one one thousand, etc.) seconds. The Target Mac will remain as a black screen but you should see the DFU box pop up in Apple Configurator window on the Host Mac:
- ALTERNATIVELY if you only have a bare board, a bad keyboard, etc. you can force DFU mode by pulling SMC_FORCE_DFU up to 1.8V using the PP1V8_SLP_S2R line. Many boards have "debug buttons" to achieve this - for example RE032 on 820-00850. You can search through the schematic for SOC_FORCE_DFU and follow it to the debug page. Be sure to use the correct port or your host system running Apple Configurator 2 will pop a "Cannot Use Thunderbolt Accessory" message, indicating that it's either NOT in DFU mode or not connected to the correct port. Also, the system may fail to revive/restore properly if the connection is persistent - thus the use of a momentary-closed button in the schematic. You can just use a large piece of jumper wire, and once the target system is connected to the host system and appearing in AC2, you can just cut the jumper wire freely. (It's a bit of a juggling act, but you could also just use tweezers to make the connection temporarily... but I've found the jumper wire method to be 100% reliable and super easy.)
For M1 MacBook Pro and MacBook Air - Make sure Mac is shut down (hold power button for 5 seconds). Plug in data cable to Host Mac (any port) then into the left-side port closest to the screen in the Target Mac. Press the power button for about half a second, then also press and hold Left Control + Left Option + Right Shift for 10 seconds, then release all keys except power and hold power until the Target Mac shows up in Apple Configurator on the Host Mac.
For Intel Mac mini and iMac Pro - Disconnect power cord from Target Mac. Plug in data cable on Target Mac to port closest to ethernet. Hold down power button and plug the power cord back in. Continue holding power button for about 3 seconds. The Target Mac will remain as a black screen but you should see the DFU logo in Apple Configurator window.
For M1 Mac mini - Disconnect Target Mac from power for at least 10 seconds. Plug in data cable on Target Mac to port closest to ethernet and into any port on Host Mac, then press and hold power while reconnecting power, then release power. The status indicator color should be amber.
For 2019 Mac Pro - Disconnect power cord from Target Mac. Plug in data cable on Target Mac to USB-C port farthest from the power button. While holding the power button, connect the power cord and continue to hold the power button for about 3 seconds.
Complete the restore through Apple Configurator. When done, verify that the process completed.
Few things from experience (inwerp):
Case: Macbook Pro 2018 15', 5V shortly 0.3A, than 0.04A-0.08 floating, all G3HOT present. Died with no particular reason, stopped charging and simply did not start up after next reboot.
- Did not work with USBA-USBC adapter (claimed to work by Apple Article), used thunderbolt cable.
- Apple Configurator shows DFU logo without key combination, but flashing in this mode will end up with a undefined error.
- Key combination works like 50/50, no particular pattern, best looks like DFU LOGO - SMC RESET Combo 4 Sec till DFU Logo disappears, shows again, now flashing works.
may end up with the connection timeout, target device will start to boot, then shutdown at some point.
Macbook Air 2018 (820-01521) no power no post, just died, stuck at 20V 0.0667A All G3H present, missing PP5V_S5.
Connected power to the USB that is close to the LCD, and the USB c to the host machine close to the Tarckpad.
Using a host MacBook air with configurator 2, manage to prompt recovery. Clicked the restore button the the process started.
The restore process stalled at the last few pixels of the progress bar, and the Target Air turned off.
Upon pressing the power button, the Target air went in to internet recovery, from where the installer prompted "Activating Mac", which got Activated.
Disk utility showed an empty disk.
In this case Data was wiped from customer's device.
Few things from experience (Liminalsunset):
DFU Restore on T2 Mac: MacBook Pro 16" 2019
It's possible to restore the T2 firmware on this machine using a MacBook Air, Mid-2013 13" laptop. It appears that a USB-C mac is not required to initiate the process.
Both systems were running Catalina 10.15.7. This does erase the SSD. I used Internet Recovery to restore a backup and it worked fine after. Activation Lock and FileVault were enabled prior to procedure and do not appear to affect it. Works with Target MacBook Pro powered off of battery.
To enter DFU mode I used:
1) Turn off MBP and plug in USB A to USB C cable (third party) from MacBook Air into MacBook Pro, port closest to you facing computer on the left side
2) Locate left Control and Option keys on MacBook Pro, as well as right Shift key.
3) Press Power button for 1 second, then hold keys above down with power button for 8 (real) seconds. MBP will flash Apple logo, then it will disappear
4) DFU device should show up in Apple Configurator 2. Rest of process is uneventful and works normally. Once restore is complete MBP may need manually powered off and on to start into Internet Recovery
Few things from experience: (Dusten Mahathy)
Unit not booting without battery present. This board will boot on a 96watt adapter normally. I have seen 3 cases where the board doesn't boot on the adapter alone, and wouldn't charge a stone dead battery normally.
Without battery connected: 20v with a jump to 300-500mA then back to 70mA and kind of sit there.
With battery connected: It would very slowly raise to charging amperage. (It would take 2 to 3 minutes for it to reach 4 and a half amps, vs the normal 30 seconds to a minute)
After diagnosing the charging circuit, and seemingly everything on the board is physically okay, I decided to DFU restore the unit, thinking something with the SMC, that T2 is now handling.
This resolved the issue.
Prohibition Symbol: This seems to be caused by the board being disabled. Flashing the T2 ROM, and restoring via DFU resolved the issue.
DFU "unknown error" codes:
1 - Battery not present(needs battery for full restore)
9 - EEPROM/T2 ROM mismatch, BridgeOS partition not found (use Restore instead of revive, will format SSD), SSD partition corrupted or similar.
75 T2 booted in recovery mode (revive wont work)
4005 SSD not detected error
4014 T2 RAM error
From Experience: (Dusten Mahathy)
The unit came in with slight liquid damage on U7650, U6940, and Q7660. Shorted was PP5V_G3S. The shorted component was U8245. After replacing U8245, I found that PP5V_G3S was 10v, instead of the 5v that it was intended for. After only a few seconds of having the board on again after replacing U8245, to check measurements, it was shorted again. At this point, I replaced U7650, Q7660, and repaired several traces and capacitors, resistors. Once again, replacing U8245. This time when powering on the board PP5V_G3S, was at its normal voltage. However, the unit still would not boot. Hovering about 20v 100mA. So after further investigation, I found PPVCCIN_AUX_PCH was not being generated. This was due to PPVCCINAUX_VCC being shorted to ground. This failed component was U7400. Which was powered by PP5V_G3S. So, after replacing U7400, I was making progress. The unit would start the boot process, getting 1v8 on PPVCC_S0_CPU for a second, then 0v, but pulsing. So on/off/on/off scenario. I found the pulsing started all the way back at PP1v8_SLPS2R. I did find, however, that if I removed R7210, R7220, and R7230 the system would be stable again. These are the three resistors that powers PPVCC_S0_CPU. At this point, I am pretty certain that I have some sort of CPU failure. Wether it be the CPU itself or not, I am not sure. I felt that it was, as I have a suspicion the 10v going through the CPU MOSFETs probably killed the CPU. However, as a last desperation, and for research, I decided to attempt to DFU the machine. At his point, it failed, and I got error code 9. This was somewhat expected, as all the power rails are pulsing currently. So what I decided to do, was remove the three resistors mentioned early, to make the system stable again. At this point, the DFU restore went through successfully. This leads me to believe that CPU failure can cause error code 9