# X619AP
Update: I've done some more research. This page isn't completely accurate, and I'll be releasing a revised copy in the future!
I learned a few interesting things today about the T1 chip in 2016/2017 MacBook Pros with Touch Bars, thought I would share them because I feel like infodumping anyway.
Apple first started using their own silicon in Mac in 2016 with the release of the 2016 MacBook Pros with Touch Bar. Be aware that the function keys model they also released doesn't have a T1 chip - no need for it to be there as it serves only a few purposes.
The T1 chip (X619AP) is a derivative of the Apple Watch Series 1's S1P chip with 1 gigabyte of memory and no internal storage, running (as of this writing, likely the same in the future too) bridgeOS 2.0.1 which is based off of watchOS 3. It only controls the following things on a 2016/2017 MacBook Pro with Touch Bar:
Touch Bar
Apple Pay, Touch ID, and other Secure Enclave operations
System management controller
A short list, but that's fine. Apple had also only just begun throwing their own ARM silicon into the Mac.
However, no internal storage makes things interesting. Reading up on how it works, it seems that macOS uploads a ramdisk to the T1 chip when the system boots. The ramdisk is personalized and likely signed as well, and it's stored on the EFI system partition of the macOS disk.
And here comes in that infamous error:
A critical software update is required for your Mac, but an error was encountered while installing the update. Your Mac can't be used until this update is installed.
This issue is often misread. Even if you have completed Setup Assistant on that Mac, it will reopen and beg you to try downloading a "software update" again, ultimately leading to a Mac that cannot be used with macOS, and is broken in Windows and Linux. Most leave the reason to a hardware failure in the T1 chip or the Touch Bar itself, but the issue is actually much simpler than that:
The ramdisk that macOS uploads to the T1 chip when booting is missing. Because of this, macOS wants to redownload it to get it working properly (otherwise, all of the stuff that the T1 chip controls will stop working.) This error shows when something went wrong with the download.
The way I can tell this *isn't* a hardware failure is by checking Apple Diagnostics. It's a pretty reliable tool for identifying issues with the hardware, even on Macs with coprocessors. I theorize that if something in the T1 was broken, it would throw one or multiple of the following errors:
Touch ID (BMT001, BMT003, BMT004, BMT005)
Touch Bar (DFR001)
SMC (PFM001 to PFM007)
Camera (NDC001, NDC003 to NDC006)
- Reports says that swapping displays can also cause the CSU bug. On T2, the camera is wired through the T2's internal USB controller. Maybe it's the same on T1?
However, most cases show that Apple Diagnostics returned ADP000 - meaning nothing is wrong with the hardware or UEFI firmware. That leaves the issue to software and what's stored on the disk.
It also explains a few things.
This user in OCLP had it happen to his machine by reformatting the internal storage. On a non-T1 Intel Mac, this would have been fine. Earlier Macs don't have a coprocessor to load firmware for, and T2 Macs have their firmware on isolated NAND (so that they can load before the Intel CPU, and Secure Boot can work.) However, formatting the internal storage on a T1 Mac leads to the embeddedOS ramdisk being wiped from the system.
Normally, during Setup Assistant (after connecting to the internet), macOS is able to redownload a personalized ramdisk for that machine. If it cannot, the CSU bug reveals itself and pain begins. This process can be verified by looking at the logs from EmbeddedOSInstallService.
I'm going to keep doing a little more research into the T1, some exciting information I found today (at least for me.) Stay tuned.
Oh - also make sure to come to my stream tonight. I have stuff to show!