I recently got my hands on one of the first Dabao evaluation boards, bunnie Huang's new dev board built around the Baochip-1x SoC. I've been bringing it up in bare metal C over the past 2 or so weeks and wanted to share some early impressions. This chip is unlike anything I've worked with before and I've worked with a lot of microcontrollers. I'm geninely impressed by how much power is packed into this tiny chip and I think it can make a great and powerful general purpose microcontroller. In fact I think "SoC" more accurately describes this device, because as I work with it, though it has the simple usability of a microcontroller, it feels very much like an SoC.
The Board
The Dabao is about the size of a stick of gum, and fits well in a small breadboard on which I've been doing most of my experiments. It has a solid pico-like form factor. The board has two 16-pin headers, a USB-C port, and two buttons. No onboard LED, no JTAG header and nothing extra. The board is deliberately minimal, the chip is the point and I kinda am liking that idea, honestly I would have liked a few more pins broken out, but we have more than enough pins broken out to do some serious damage!
Crowd Supply Image
That chip on board is of course the is the Baochip-1x, fabricated by TSMC in 22nm. In case you missed the specs, this board features a 350 MHz VexRiscv RISC-V CPU with an MMU, 4 MB of on-chip ReRAM (non-volatile, like flash but different physics), 2 MB of SRAM, USB 2.0 HS, and the thing that makes this chip genuinely special, a quad-core 700 MHz I/O coprocessor called the BIO. ReRam is really cool when you start using it, and I've been working on a driver to make it easy to use from C.
The whole thing also has hardware AES, SHA-256, a true random number generator, key storage, glitch sensors, and a security mesh. This isn't a hobby microcontroller wearing a security hat. It's a security chip that happens to be a capable general-purpose microcontroller. I am more interested though in the latter, though I must say I am surpised at how easy the security engine is to use on this chip!!
Don't belive me? Here are some snippets from experimeting with SHA:
static void hash_engine_init(void)
{
/* Enable hash clock */
SCE_SCEMODE = 0;
SCE_SUBCLKEN |= (1 << 2); /* HASH clock enable */
__asm__ volatile ("fence" ::: "memory");
/* Load SHA-256 H and K constants into LKEY buffer */
uint32_t offset = 0;
hash_load_u32(SHA256_H, HASH_LKEY_BUF + offset/4, 8);
offset += 32; /* 8 words = 32 bytes */
hash_load_u32(SHA256_K, HASH_LKEY_BUF + offset/4, 64);
offset += 256; /* 64 words = 256 bytes */
/* Trigger INIT function to load constants into the hash engine */
HASH_OPT3 = 0; /* big-endian */
HASH_CRFUNC = HF_INIT;
hash_trigger();
hash_wait_done();
}
And a test:
/* ---- Test 4: SHA-256 of 32 zero bytes ---- */
mini_printf("[Test 4] SHA-256(32 zero bytes):\r\n");
uint8_t zeros[32];
for (int i = 0; i < 32; i++) zeros[i] = 0;
rc = sha256_hash(zeros, 32, digest);
mini_printf(" Result: "); print_hex(digest, 32); mini_printf("\r\n");
mini_printf(" Expected: 66687aadf862bd776c8fc18b8e9f8e20089714856ee233b3902a591d0d5f2925\r\n");
mini_printf(" Status: %d\r\n\r\n", rc);
Here's something that isn't obvious from looking at the Dabao board. The Baochip-1x shares its silicon die with another chip called the Daric, made by Crossbar, a Santa Clara company that holds over 160 patents on Resistive RAM technology. Crossbar designed a complete security chip around their RRAM, targeting blockchain and digital asset security and that chip has an ARM Cortex-M7 CPU, the same RRAM, the same crypto accelerators, the same peripheral set. The Baochip-1x and the Daric are manufactured on the same mask at TSMC, same wafer. At chip probe time, fuse bits determine which CPU is active.
This means when you're writing bare metal C for the Baochip-1x, the Crossbar Daric SDK and documentation become a second source of truth for the peripheral set. The UDMA engine, the SCE crypto block, the IOX crossbar, these are Crossbar IP that bunnie integrated with his open RISC-V core. When the Baochip docs are thin, the Daric reference material fills in gaps, if you know where to look. My experience has been it's a rather "heavy" SDK and has a lot of ARM stuff, but it does provide a some help if you're working with the device.
What Makes It Different
Three things stand out immediately when you start writing bare metal C for this chip. First, the UDMA subsystem. Every serial peripheral on the Baochip-1x (UART, SPI, I2C, SDIO, camera, I2S) goes through a micro-DMA engine. There's no "write a byte to a data register" path for transmit. You allocate a buffer, set a source address, a size, and a config register, and the DMA engine moves the data. It's more setup than a traditional microcontroller but it scales beautifully. Sending 1000 bytes takes the same CPU effort as sending 1.
The catch though is that those DMA buffers must live in a special memory region called IFRAM at 0x50000000. Not in SRAM like yuo would think, if you put your UART transmit buffer in SRAM, nothing happens. You won't see any errors, or crashes, just silence. The DMA engine's address decoder simply can't reach SRAM. This is the kind of thing that eats hours of your day if you don't know about it.
Second, is the BIO coprocessor. Think of it as PIO on the Raspberry Pi Pico, but instead of 9-instruction state machines with 32 instructions of program memory, you get four full RISC-V CPU cores (PicoRV32, RV32-EMC) each with 4 KB of RAM, running at 700 MHz. You write standard RISC-V assembly, not some custom state machine language. At 700 MHz you can bit-bang SPI at 25 MHz or drive WS2812 LEDs with precise timing. The BIO cores have register-mapped GPIO, inter-processor FIFOs, and event signaling. It reminds me of the Propeller's cogs, except each cog is a real CPU running at 700 MHz with a proper instruction set. So far in quick test I was able to blink some LED's with the thing and am working on a formalized driver.
Third, the RTL source code is public. The digital logic for this chip is on GitHub, written SystemVerilog (thankfully). When the documentation is thin (and it is thin, but is improving over time), you can read the actual hardware description and figure out what a register does. I've been living in the RTL for the past few weeks and it's been both enlightening and occasionally surprising. It's amazing to have some quirk and relize "hey I can just see what the RTL is doing" and kinda figure things out that way, it's a differnt way of writing software..
Technical Nugggets about The Boot Chain, Memory Map and Clock Tree
Without being unecessarily lengthy, one of the things I like but at the same time took me a minute to appreciate is booting the chip. Getting code onto this chip is more involved than most microcontrollers. The Baochip-1x has a signed boot chain that goes something like this: ROM bootloader -> boot0 -> boot1 -> your firmware. Every stage verifies the next stage's Ed25519 digital signature before jumping to it. Your bare metal binary needs to be signed with the published developer key and packaged into the UF2 format. The signature uses Ed25519ph (the prehashed variant from RFC 8032), not standard Ed25519 so a standard Ed25519 signing tool won't work. The first 768 bytes of your image are the signature block, which starts with a JAL instruction that jumps over the signature data to your actual code at 0x60060300.
It sounds complicated and it is, but once your signing tool is working you don't think about it again. Flash your UF2, press reset, your program just runs. When you consider the security benefits this process brings it's definatly worth the effort.
If you're wondering what the memory of the chip is like, the Baochip-1x has four distinct memory regions and understanding them is critical before you write a single line of code, so you kinda need to keep a mental model of the mmeroy layout as you work with the chip.
RRAM sits at 0x60000000, which has 4 megabytes of non-volatile storage. This is where your compiled code lives and executes in place. The boot chain occupies the bottom, boot0 from 0x60000000, boot1 from 0x60020000, and your code loads at 0x60060000. The upper portion is available for persistent data storage, which I've verified survives power cycles.
SRAM lives at 0x61000000 and gives you 2 megabytes of fast volatile RAM for your stack, globals, and heap. One hardware gotcha yuo gotta know though is that SRAM bank 0 requires a write wait state to be configured before you can trust writes to it. boot0 handles this, but if you ever bypass boot0, you'll get intermittent write corruption that is maddeningly difficult to track down (don't ask lol).
Then there's IFRAM at 0x50000000, which is two 128 KB banks of I/O frame RAM. This is the memory region I mentioned earlier that the UDMA engine requires for all DMA buffers. It exists in a completely separate address space from SRAM and if you've used STM32 DMA or ESP32 DMA, forget what you know. On those chips, DMA can access any RAM but on the Baochip-1x, the DMA engine's address bus physically cannot reach SRAM. Your DMA buffers go in IFRAM or they silently do nothing, theres no error flag, no fault, just a transfer that never happens, maybe I missed somethign but thats something you gotta look out for, the BIO though makes it easy to do M2M DMA, surpisingly easy I might add!
Peripheral registers are memory mapped starting at 0x40000000, with the UDMA cluster at 0x50100000 and the IOX at 0x5012F000.
When using chips the last thing that's usually a pain is the clocking so I'll share some stuff I discorved when working with the board. The clock system starts with a 48 MHz crystal oscillator and multiplies up through a PLL. In theory, the PLL has a fractional divider for hitting precise frequencies, in practice from working with the chip I have found that the fractional divider doesn't work, its integer only, from 48 MHz, this means certain target frequencies are impossible to hit exactly.
The default boot configuration produces a clock tree I've verified on hardware with an oscilloscope, 700 MHz for the BIO coprocessor (FCLK), 350 MHz for the CPU (ACLK), 43.75 MHz for the APB peripheral bus (PCLK), and 99 MHz for the UDMA peripheral clock (perclk). That 99 MHz is interesting. You'd expect 100 MHz, but with integer-only division from 48 MHz, 99 MHz is the closest you get. If you calculate your UART baud rate divisor assuming 100 MHz, your baud rate will be off by 1% which is not enough to break communication, but enough to raise an eyebrow on a logic analyzer, the reality is though using the chip I haven't really noticed it at all.
One more thing about clocks you should know is that every clock domain has a gate register, but writing to the gate register doesn't take effect immediately. You have to write a commit value (0x32) to a separate register called SFR_CGUSET. Forget the commit and your clock change silently doesn't happen, this caught me at first so look out for that.
What I've Found So Far
I've been working on a bare metal C sdk for this powerhouse and have been working through the peripherals one by one. GPIO was straightforward once I understood the I/O crossbar (they call it the IOX). The chip has six ports with per-pin control of alternate functions, pull-ups, drive strength, slew rate, and Schmitt triggers. UART works through the UDMA engine. Once you understand the IFRAM buffer requirement and the UDMA channel pattern (SADDR, SIZE, CFG), the same pattern applies to SPI and I2C. It's a powerful way to do things once you understand how the chip works, you just kinda "get it".
There are quirks. Definitely quirks. The kind you only find by putting code on real silicon and watching what happens on an oscilloscope. I'll write those up in detail as I go. I'm building a full bare metal C SDK with Pico-style ergonomics and I'm keeping notes on everything, don't worry you guys won't be in the dark.
Who Is This Chip For?
The Dabao is $9.50 on Crowd Supply. At that price point, with this feature set, I think it sits in a unique spot. If you care about open-source silicon, this is as close as you can get to seeing every transistor in your microcontroller. If you care about hardware security, this chip has features that normally live behind NDAs and six-figure minimum order quantities. If you're the kind of embedded developer who likes reading Verilog to understand why a peripheral behaves the way it does, you're going to have a good time. It is definately a powerful way to write firmware.
It's not a drop-in replacement for a Pico or an ESP32. The ecosystem is young, but the power you gain is definately worth it. The documentation is the RTL source code. But for a chip that's essentially first silicon in the hands of developers, I'm impressed by how much works and how well it works.
After spending some time with this chip, the closest comparison I can offer is: imagine if someone took a Raspberry Pi Pico, replaced the PIO with something closer to a Parallax Propeller's cogs, added an SAMD21-style DMAC (but more opinionated about buffer placement), dropped in a hardware security module from a banking-grade secure element, and then published the gate-level source code for the whole thing. That's the Baochip-1x.
The 350 MHz VexRiscv core puts it between the RP2040 (133 MHz Cortex-M0+) and the Teensy 4.1 (600 MHz Cortex-M7) in raw compute. The BIO coprocessor at 700 MHz with four cores and 4 KB each outclasses PIO in programmability and approaches what the Propeller does with cogs, except each core runs a real RISC-V ISA instead of a proprietary instruction set. The security features (AES, SHA, TRNG, key store, glitch sensors, security mesh) are things you normally see on chips that require NDAs and six-figure MOQs.
There's nothing else quite like it on the market right now. And at $9.50 for the eval board, as soon as they get back in stock I definately recommend you pick up a couple!
More posts coming as I dig deeper into the peripherals and the BIO coprocessor. There's a lot to cover.
Armstrong Subero is an Embedded R & D Engineer, published author (four books with Springer/Apress). He loves RISC-V and builds the Rovari platform from Trinidad and Tobago.
Learn, build and ship with RISC-V from Anywhere. Thats the Rovari Way.
Follow the project: rvembedded.com · @rvembedded
P.S Typos in this post were not corrected as validation its human generated content.