Power-on self-tests (POST) are widely used in electronics, and one of the oldest features of personal computers. Every model of Mac in the past has had its own POST routines, some that have become famous because of the sounds that result, or what’s displayed, from the sight of a Sad Mac to the sound of a car crash. So what happens when an Apple silicon Mac fails its POST? Does it even run them?

One catch here is recalling that POST routines may not be run for a restart, as they normally need a ‘cold’ start from the Mac being shut down. The first place to look is where Macs normally report the results of their last POST, in the Diagnostics item of System Information. While that does report the results of the last Diagnostics test run (if any), for Apple silicon Macs there’s no mention of any POST, as there is on Intel Macs, even those with a T2 chip.

Those are normally retrieved from NVRAM, but as far as I can see, Apple silicon Macs don’t have anywhere in their NVRAM where they might store the result of a POST.

Maybe Apple silicon Macs do still run POST, but haven’t yet found a good way to report it? To discover whether that’s feasible, you need to compare what happens in their boot sequences.

With two separate processors in each T2 Mac, there are two separate sets of firmware, one EFI and the other known as iBridge or BridgeOS.

Once a T2 Mac has performed its POST and initialised the SMC, the T2 sub-system establishes the level of Secure Boot in force, and, if that’s Full or Medium Security, boot.efi is checked before being loaded, and that leads through to the rest of the boot process.

In contrast, boot security in Apple silicon Macs aims to provide a verified chain of trust through each step in the boot process to the loading of macOS, that can’t be exploited by malicious components. Booting an M-series Mac thus starts with the immutable Boot ROM in the hardware, whose most important task is to verify the executable for the next stage, then load and run it. If that isn’t possible, then the fallback is to go into DFU mode and await a connection over USB.

As with Intel Macs, there’s no accessible record in the log of what has happened during the initial phase of the boot process, as log records only begin with the kernel. Prior to that are ‘breadcrumbs’ that are only intelligible to Apple’s engineers. In the event of early boot failure, the only recourse seems to be to abandon the process, and leave the Mac in DFU mode. At that stage, the alternative would be to try to start up in Recovery mode, possibly flashing the power light provided on some models.

Most of the plethora of devices within the SoC don’t load their firmware and start running until after the kernel has started loading. Until then, all code has been run on a single core too, and the other cores aren’t run up until after the kernel is busy initialising the Mac. So a POST run from the Boot ROM wouldn’t be able to test much of the chip, and wouldn’t have much hardware for which to indicate any problems it might find.

Intel-based Mac models from before October 2016 signal the outcome of their POST phase using sound. A normal startup chime indicates that memory (RAM) and ROM appear sound and sufficient for the boot process to continue. The following sounds are emitted when booting is abandoned or paused:

• if no RAM is found, a single tone repeated every 5 seconds;
• if RAM is found but fails POST, three tones followed by a 5 second pause, repeating
• if the EFI firmware found is corrupt and is being recovered, three long, three short, and three long tones (—…—, the inverse of Morse SOS)
• if an EFI firmware update is in progress on a Mac model prior to 2012, one long tone when you hold the Power button.

Recent MacBook Pro and some other models that have mute boots neither emit sounds nor flash their displays if they encounter problems during their POST. If they can’t find a valid EFI firmware source, they should automatically recover the EFI firmware, but without any sounds to provide a clue that is what is taking place; instead, they display a white-on-black progress bar when trying to recover their firmware.

Apple silicon Macs are different in their hardware, in that much of it is integrated into the single M-series chip, and memory is built into the chip carrier. Old remedies for POST failure such as shutting down and reseating memory modules simply don’t apply.

So there are no accessible records of any POST taking place on Apple silicon Macs, no other evidence that they do, and even if they did it’s hard to see what they might achieve. It does look like Apple has sounded the last POST, unless you know any better.

Further reading

Wikipedia
Mac startup process on Wikipedia