Thanks to all the backers who have contributed to the campaign so far, plus a special shout-out to those who have generously donated to support my work! As a subscriber to the “Dabao” campaign, you’re already aware of the Baochip-1x. This update fills in the backstory of what it is, why I’m doing it now, and how it came about.

Hardware Built to Run High-Assurance Software

In my mind, the Baochip-1x’s key differentiating feature is the inclusion of a Memory Management Unit (MMU). No other microcontroller in this performance/integration class has this feature, to the best of my knowledge. For those not versed in OS-nerd speak, the MMU is what sets the software that runs on your phone or desktop apart from the software that runs in your toaster oven. It facilitates secure, loadable apps by sticking every application in its own virtual memory space.

The MMU is a venerable piece of technology, dating back to the 1960’s. Its page-based memory protection scheme is well-understood and has passed the test of time; I’ve taught its principles to hundreds of undergraduates, and it continues to be a cornerstone of modern OSes.

Diagram illustrating an early virtual memory scheme from Kilburn, et al, 'One-level storage system', IRE Transactions, EC-11(2):223-235, 1962

When it comes to evaluating security-oriented features, older is not always worse; in fact, withstanding the test of time is a positive signal. For example, the AES cipher is about 26 years old. This seems ancient for computer technology, yet many cryptographers recommend it over newer ciphers explicitly because AES has withstood the test of hundreds of cryptographers trying to break it, with representation from every nation state, over years and years.

I’m aware of newer memory protection technologies, such as CHERI, PMPs, MPUs… and as a nerd, I love thinking about these sorts of things. In fact, in my dissertation, I even advocated for the use of CHERI-style hardware capabilities and tagged pointers in new CPU architectures.

However, as a pragmatic system architect, I see no reason to eschew the MMU in favor of any of these. In fact, the MMU is composable with all of these primitives – it’s valid to have both a PMP and an MMU in the same RISC-V CPU. And, even if you’re using a CHERI-like technology for hardware-enforced bounds checking on pointers, it still doesn’t allow for transparent address space relocation. Without page-based virtual memory, each program would need to be linked to a distinct, non-overlapping region of physical address space at compile time, and you couldn’t have swap memory.

This begs the question: if the MMU is such an obvious addition, why isn’t it more prevalent? If it’s such an obvious choice, wouldn’t more players include it in their chips?

“Small” CPUs such as those found in embedded SoCs have lacked this feature since their inception. I trace this convention back to the introduction of the ARM7TDMI core in the 1990s. Back then, transistors were scarce, memory even more so, and so virtual memory was not a great product/market fit for devices with just a couple kilobytes of RAM, not even enough to hold a page table. The ARM7TDMI core’s efficiency and low cost made it a runaway success, shipping over a billion units and establishing ARM as the dominant player in the embedded SoC space.

Fast forward 30 years, and Moore’s Law has given us tens of thousands of times more capability; today, a fleck of silicon smaller than your pinky nail contains more transistors than a full-sized PC desktop from the 1990s. Despite the progress, these small flecks of silicon continue to adhere to the pattern that was established in the 1990s: small systems get flat memory spaces with no address isolation.

Die shot of a modern 22nm system-on-chip (SoC). This fleck of silicon is about 4mm on a side and contains more transistors than a desktop PC from the 1990’s. Despite this, the logic region is more empty space by area than active gates

The root cause turns out explicitly to be because MMUs are so valuable: without one, you can’t run Linux, BSD, or Mach. Thus, when ARM split their IP portfolio into the A, R, and M-series cores, the low-cost M-series cores were forbidden from having an MMU to prevent price erosion of their high-end A-series cores. Instead, a proprietary hack known as the “MPU” was introduced that gives some memory security, but without an easy path to benefits such as swap memory.

We’ve been locked into this convention for so long that we simply forgot to challenge the assumptions.

Thanks to the rise of open architecture specifications such as RISC-V, and fully-open implementations of the RISC-V spec such as the Vexriscv, I’m not bound by anyone’s rules for what can or can’t go onto an SoC. And so, I am liberated to make the choice to include an MMU in the Baochip-1x.

This naturally empowers enthusiasts to try and run Linux on the Baochip-1x, but we (largely Sean ‘xobs’ Cross and me) already wrote a pure-Rust OS called “Xous” which incorporates an MMU but in a framework that is explicitly targeted towards small memory footprint devices like the Baochip-1x. The details of Xous are beyond the scope of this post, but if you’re interested, check out the talk we gave at 39C3.

“Now” Is Always the Right Time to Choose More Open Frameworks

This couples into the core argument as to why a “mostly open RTL” SoC is the right thing for this moment in time. As a staunch advocate for open-source technologies, I would love to see a fully-open silicon stack, from the fabs-up. I’m heartened to see multiple initiatives working on fixing this problem, but it’s a hard problem. I estimate it could take more than a decade before we have a sufficiently robust open source silicon ecosystem to market economically competitive SoCs.

For those of us looking to create an embedded product today, that leaves only one practical option: continue to use Cortex-M ARM devices, and if we want hardware memory protection, we have to tune our software to their proprietary MPU. This means further entrenching our code bases in a proprietary standard. Do I really want to spend my time porting Xous to use ARM’s proprietary flavor of memory protection? Surely not.

Thus, I would argue that we simply can’t afford to wait for fully open source PDKs to come along. Given the opportunity to do a partially-open RTL tapeout today, versus waiting for the perfect, fully-open source solution, the benefit of taping out partially-open RTL SoCs today is crystal clear to me.

A partially-open SoC available today empowers a larger community that is interested in an open source future, even if they aren’t hardware experts. As a larger community, we can begin the process of de-leveraging ARM together, so that when economically viable, “truly open” silicon alternatives come to market, they can drop directly into a mature application stack. After all, software drives demand for silicon, not the other way around.

The good news is that on the Baochip-1x, everything that can “compute” on data is available for simulation and inspection. The parts that are closed are components such as the AXI bus framework, USB PHY, and analog components such as the PLL, voltage regulators, and I/O pads.

Thus, while certain portions of the Baochip-1x SoC are closed-source, none of them are involved in the transformation of data. In other words, all the closed source components are effectively “wires”: the data that goes in on one side should match the data coming out the other side. While this is dissatisfying from the “absolute trust” perspective, one can’t definitively rule out the possibility of back doors in black-box wires, we can inspect its perimeter and confirm that, for a broad range of possibilities, it behaves correctly. It’s not perfect transparency, but it’s far better than the fully-NDA SoCs we currently use to handle our secrets, and more importantly, it allows us to start writing code for open architectures, paving a roadmap to an eventually fully-open silicon-to-software future.

Hitchhiking for the Win

Those with a bit of silicon savvy would note that it’s not cheap to produce such a chip, yet, I have not raised a dollar of venture capital. I’m also not independently wealthy. So how is this possible?

The short answer is I “hitchhiked” on a 22 nm chip designed primarily by Crossbar, Inc. I was able to include a CPU of my choice, along with a few other features, in some unused free space on the chip’s floorplan. By switching off which CPU is active, you can effectively get two chips for the price of one mask set.

Floorplan of the Baochip, illustrating the location and relative sizes of its 5 open-source CPU cores

For those who haven’t peeked under the hood of a System-on-Chip (SoC), the key fact to know is that the cost of modern SoCs is driven largely by peripherals and memory. The CPU itself is often just a small fraction of the area, just a couple percent in the case of the Baochip-1x. Furthermore, all peripherals are “memory mapped”: flashing an LED, for example, entails tickling some specific locations in memory. Who does the tickling doesn’t matter – whether ARM or RISC-V CPU, or even a state machine – the peripherals respond just the same. Thus, one can effectively give the same “body” two different “personalities” by switching out their “brains”; by switching out their CPU cores, you can have the same physical piece of silicon run vastly different code bases.

The long answer starts a couple years ago, with Crossbar wanting to build a high-performance secure enclave that would differentiate itself in several ways, notably by fabricating in a relatively advanced (compared to other security chips) 22 nm process and by using their RRAM technology for non-volatile storage. RRAM is similar to FLASH memory in that it retains data without power but with faster write times and smaller (32-byte) page sizes, and it can scale below 40 nm – a limit below which FLASH has not been able to scale.

In addition to flexing their process superiority, they wanted to differentiate by being pragmatically open source about the design; security chips have been traditionally been wrapped behind NDAs, despite calls from users for transparency.

Paradoxically, open source security chips are harder to certify because the certification standards such as Common Criteria evaluates closed-source flaws as “more secure” than open-source flaws. My understanding is that the argument goes something along the lines of, “hacking chips is hard, so any barrier you can add to the up-front cost of exploiting the chip increases the effective security of the chip overall”. Basically, if the pen tester doing a security evaluation judges that a bug is easier to find and exploit if the source code is public, then, sharing the source code lowers your score. As a result, the certification scores of open source chips are likely much worse than that of a closed source chip. And, since you can’t sell security chips to big customers without certifications, security chips end up being mostly closed source.

Kind of a crazy system, right? But if you consider that the people buying oodles and oodles of security chips are institutions like banks and governments, filled with non-technical managers whose primary focus is risk management, plus they are outsourcing the technical evaluation anyways, the status quo makes a little more sense. What’s a banker going to do with the source code of a chip, anyway?

Crossbar wanted to buck the trend and heed the call for open source transparency in security chips and approached me to help advise on strategy. I agreed to help them, but under one condition: that I would be allowed to add a CPU core of my own choice and sell a version of the chip under my own brand. Part of the reason was that Crossbar, for risk reduction reasons, wanted to go with a proprietary ARM CPU. Having designed chips in a prior life, I can appreciate the desire for risk reduction and going with a tape-out proven core.

However, as an open source strategy advisor, I argued that users who viewed open source as a positive feature would likely also expect, at a minimum, that the CPU would be open source. Thus I offered to add the battle-tested CPU core from the Precursor SoC – the Vexriscv – to the tapout, and I promised I would implement the core in such a way that even if it didn’t work, we could just switch it off and there would be minimal impact on the chip’s power and area budget.

Out of this arrangement was born the Baochip-1x.

Bringing the Baochip-1x Into the Market

At the time of writing, wafers containing the Baochip-1x design have been fabricated, and hundreds of the chips have been handed out through an early sampling program. These engineering samples were all hand-screened by me.

However, that’s about to change. There’s currently a pod of wafers hustling through a fab in Hsinchu, and two of them are earmarked to become fully production-qualified Baochip-1x silicon. These will go through a fully automated screening flow. Assuming this process completes smoothly, I’ll have a few thousand Baochip-1x’s available to sell. More chips are planned for later in the year, but a combination of capital constraints, risk mitigation, and the sheer time it takes to go from blank silicon to fully assembled devices puts further inventory out until late in 2026.

Rather than waiting until the supply chain was fully stabilized, I decided to take a small risk and share the first few thousand chips with developers like you through the Dabao evaluation board pre-order campaign. After working on this project for a couple years in total silence, I’m excited to start building a community around it. Despite the effort I’ve put into the project, there’s loads more to be done: documentation to be written, drivers to bring up, and more programming languages and OSes to support. While I personally champion the Rust-based “Xous” OS, it doesn’t have to be the only, or even the primary, code base for Baochip. I’m hoping to empower a few good open source community leaders with accessible hardware security primitives, so we can all build a brighter, more secure, and more trustable open source future together.