Project Start! UART gizmos and contribution tips

Happy new year, everyone! We're finally in 2021, and it's time to formally kick the project off! Thank you so much to everyone who pledged - it really means a lot to me to be able to do this as a job. I hope I can meet everyone's expectations :-)

I'd like to give another shout-out to those who donated hardware to help get everything started:

• Ben Stahlhood II, who sponsored a Mac Mini
• Drew Fisher, who sponsored a MacBook Air (arriving next week)
• Patrick Bernier, who sponsored a MacBook Pro

Site, logo, etc

I'm still working on this part; I'm prone to prioritizing the technical aspects... but stay tuned, I'm making progress on this front too.

Bring-up process

As those who follow my Twitter probably saw, I figured out how to get a debug UART enabled on an external Thunderbolt port (thanks to the t8012dev team for the USB-PD command info). This is step 0 of the bring-up process, a way of getting a low-level communications channel that is simple enough to use to enable debugging the rest of the boot process. The prototype hardware uses an Arduino and a FUSB302 USB-PD interface IC, and the code is up on GitHub. I am planning to design a "production" version of this as an open hardware design, and I am considering making either a small home-made run myself (10-20 units), or handing it off with someone with more manufacturing experience if there is more demand. If you are interested in such a device, please leave a comment below. Keep in mind that this is only useful for low-level kernel bring-up and development.

Next I will be putting together successive stages of bootloader code, which will also serve as a simple testbed for experimenting with hardware in a more robust way than trying to do so under Linux. I will be basing the initial stages on mini, a minimal scaffolding/OS that I wrote for ARM926EJ-S over a decade ago, meant for the Nintendo Wii's security coprocessor. This isn't necessarily going to be the final bootloader that we use for end-users, but it's convenient for initial experimentation, is very lightweight and hackable, and already contains a UART protocol for remote interaction using Python scripts on a host machine. I will port it to ARMv8, rip out all the useless Wii-specific bits, and, once UART mode works, add a USB gadget (dwcusb) driver to have a higher speed communications channel (this will also make the UART cable largely unnecessary for most work at this point; I will probably also write an earlyprintk driver for Linux based on this at some point, again so people can do low-level debug without using special cables).

Contributions

Quite a few people have already contacted me with intent to help the project! Here are some tips if you're having trouble figuring out how this works.

If you're new to this kind of low-level development but would like to learn more and help out, start by lurking in the community! I will be doing development streams and there will be public development chat channels, so try to follow along with what we're doing. Don't worry if not everything makes sense, you can take your time. You might find that a particular bit interests you in particular and then research that area to learn more. Feel free to ask questions!

If you're already experienced in this kind of stuff feel free to jump right in; a few people already have. You already know how this works. This isn't a closed team or anything like that, it's an open source community project. Ping me on IRC (marcan@freenode).

If you'd like to contribute to aspects outside the core software dev at this point (e.g. website, community management, etc.), send me an email at marcan@marcan.st. It's pretty early and I'm still working out what shape the community will take, so I want to make sure things work out the way I want them to :)

A priori, I will be scribbling down notes and hardware/software info on the GitHub wiki of the docs repo. I have previously maintained MediaWiki instances for this kind of thing, but honestly it get kind of tiring to add one more to maintain and keep updated, so I'm going to be going with this more bare-bones approach for now. GitHub wikis are just git repositories, so the contents are portable should we need to migrate. I have just enabled public editing, so feel free to fix any mistakes you find or add your own findings! In the future, this might become more curated formatted docs maintained in the repository itself, but at this stage of the project a wiki is the best fit.

Also, expect some random development streams on my YouTube channel coming up. No schedule yet, so subscribe and hit the bell to catch them when they happen! (They will be archived, don't worry).

I'm really looking forward to making Linux on M1 happen soon!