End of batch, and not planning another run for a while

What is it?

The Central Scrutinizer connects to an Apple M1/M2/M3 machine over USB-C, and exposes the integrated low-level serial lines that 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 or perform a DFU update.

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!

If you want to see the capture of a real serial session: https://asciinema.org/a/BK9hEUMA2uZ2QP0yDZoKnsIGg (my own M1 mini booting Linux).

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. Yet.

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 to a downstream host

The latest batches come in ENIG (gold) finish, making the assembly really easy.

The Pico is in charge of the PD negotiation, USB-C orientation, and of bridging the serial lines with USB. Plenty of CPU cycles left for some on-board processing if you need it (the firmware runs on a single CPU).

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)!

If you are an established open-source developer and need multiple of these for your project, please get in touch directly rather than buying on Tindie. We can work out more economical solutions than one-off buys.

Random 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 while it works very reliably for me and a number of other kernel developers, 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.

Shipping: cheap, fast, reliable. Pick two.

• I try to offer multiple shipping options to strike a balance between cost and speed
• So far, DHL has been extremely reliable. They sometimes mis-route a parcel, but they fix that by themselves. When nothing wrong happens, they are pretty quick too. They are therefore bloody expensive
• I used to use Hermes/EVRI. They are pretty slow, and not very predictable. But they also destroyed a shipment (picture on request), which means I don't want to use them anymore. If you want to save on shipping and are prepared to take that risk, please get in touch.
• If you're in the UK, Royal Mail is the sensible option: cheap and reliable.
• And if you know of a reliable and cheap carrier in the UK, please let me know. I'm happy to offer choice as long as it is not too much of a hassle.

Last note related to shipping:

You'd think that a company dedicated to transporting goods around the world (such as DHL) would recognize that there is a bit more than the basic ASCII character set when it comes to describing names and addresses. Alas, that's all they understand. Their ignorance goes as far asking for "English characters". Morons.

So please make sure your name and address fit in the base 7bit ASCII set by providing a transliteration.