Now shipping version 3.2!

What is it?

The Central Scrutinizer connects to an Apple M1 or M2 machine over USB-C, and exposes the integrated low-level serial lines that are accessible from the DFU port over a convenient USB connection (USB CDC -- no special driver needed). It is also capable of performing a hard-reset of the machine if you've crashed it by talking to the Mac's PD controller. Finally, it offers a USB2.0 pass-through that can be used to boot the machine over USB using the m1n1 bootloader that is part of the Asahi project.

It provides a low-level debugging port to operating system developers, which is useful when you cannot count on a display to be available, or need to log information but can't use any local storage. If you're using MacOS on your Apple Silicon machine, you probably don't need the serial console aspect, but the reboot feature could prove useful if you crash the machine and need to remotely reset it.

Note that the Central Scrutinizer board is not a stand-alone device. You will need to solder a Raspberry-Pi Pico to it, build and flash some firmware to make it usable. If you want a fully built device, please select the "with a Pico" option. Each and every board gets tested before shipping (yes, this takes some time), even those without a soldered Pico, so there should not be any surprise at assembly time.

It shouldn't be too hard to port the firmware to another type of micro-controller, or even to a high-level OS such as Linux, but you'd lose the pretty tight physical matching with the Pico board. However this is all open-source code and HW, feel free to hack on it and contribute your changes!

Cables and capabilities

The USB-C cable between the board and the Mac conditions the feature set:

• cables containing the SBU signals are capable of serial console, reboot and USB pass-through (cables capable of DP over USB-C carry these signals)
• cables without the SBU signals are only capable of serial console and reboot (that's most/all USB2.0 cables)

Cables with an e-marker get the VCONN supply (5v), but the firmware doesn't take any advantage of it at this stage.

What's onboard?

Here's a laundry list of what the board contains:

• a FUSB302 PD controller to communicate with the Mac's own PD controller
• a pair of level shifters ensuring adaptation of the 1.2v signalling on the Mac side to the much more common 3.3v
• a set of switches routing the D+/D- and SBU signals between the Mac, the Pico serial port and the on-board micro-USB connector
• a 1.2v LDO to power the level shifters
• a MOSFET to control the VBUS signalling
• a USB-C connector to connect to the Mac
• a micro-USB connector to expose the D+/D- lines

The Pico is in charge of the PD negotiation, USB-C orientation, and of bridging the serial lines with USB.

Why did you make it?

I'm a Linux kernel developer, mostly working on the arm64 port. Having such a low-level tool helps debugging in situation where I can't rely on anything else to be working (it fits my personal flow, but that's not necessary everyone's). It also mean that I can stack these machines without having any screen or keyboard attached to them (or closed on a shelf in the case of a laptop)!

Notes

• Both the hardware and software are open-source.
• You are actively encouraged to build your own, and contribute the changes you make (I take patches)!
• Please read both the hardware and software documentation (there is a README in each of the repositories). Understand that this is a work in progress, that although it works reliably for me and a number of others, it is likely to have bugs and a bit of an attitude!
• This isn't a full fledged BMC. It really only exposes a USB serial port with some added goodies such as being able to reboot the machine in about any situation, not much else. It could complement a BMC (such as PiKVM) though, and be used in an environment that requires direct console access (remote server management).
• If you have questions, requests or ideas, feel free to message me.