Week Log: Fleeing to Dumplings While Getting Linux onto a RISC-V Board

Monday morning, a new RISC-V board had arrived on my desk. I was already mentally sketching out the boot sequence as I tore open the package — by Tuesday, I'd painfully realised just how naive that was.

Monday — Unboxing and First Struggles

The board was smaller than I expected. About two credit cards stacked together, with a RISC-V core, 512MB of RAM, and a surprisingly generous GPIO pin layout. Getting the UART connected and a serial console up went fine. The problem was U-Boot. The vendor-supplied BSP was based on a branch that subtly diverged from mainline, so the device tree source didn't play nicely with my cross-compilation toolchain. After chasing dtc version mismatch errors for three hours, I gave up and patched the dtb myself.

I skipped lunch. Bad call.

Tuesday — Kernel Panic and Back-Alley Dumplings

I kicked off a kernel build first thing and brewed some coffee. The build succeeded, but the moment I flashed it onto the board — kernel panic. Digging through the serial log, I found the memory mapping addresses differed between the vendor documentation and the actual hardware. Never trust the docs. Oldest lesson in embedded, and it gets me every single time.

By lunchtime I couldn't bear to look at a monitor any longer, so I stepped out. Wandered into a back alley in the Melbourne CBD and ordered a plate of prawn dumplings at a shabby little shop. Dipping them in vinegar fresh out of the steamer, I made peace with the fact that I'd have to redo the memory map by hand. The place was packed with the lunch rush, and I sat in a corner scribbling address offsets in my notebook.

A busy Melbourne laneway with a small dumpling shop and steaming baskets

Wednesday–Thursday — From Boot to Shell

Wednesday morning, I revised the memory map based on a hardware register dump and rebuilt. The kernel came up, but this time it stalled at initramfs. busybox init wasn't executing properly, so I tried mounting rootfs manually. When I saw that no block devices were showing up under /dev, I suspected the MMC driver. A diff against the vendor kernel source confirmed it — one patch was missing.

Thursday, 3:47 PM — a shell prompt finally appeared. The moment I saw # blinking on the serial console, I shot up from my chair. This is what all the struggle is for. I immediately combed through dmesg to check driver load status. Networking wasn't up yet, but the filesystem was alive, so I was at least halfway there.

That evening, by way of celebration, I had xiao long bao near Flinders Lane. The broth was so hot it burned the roof of my mouth, and even that felt good.

Serial console showing a Linux shell prompt on a dark monitor

Friday — Wrapping Up and Remaining Homework

Getting the Ethernet driver up would have to wait until next week. I spent Friday organising the week's work in git and documenting the whole ordeal on the team wiki. Key pitfalls with the vendor BSP, device tree modification points, the MMC driver patch — so the next person doesn't fall into the same holes.

Look, the RISC-V ecosystem still has a long way to go compared to ARM. BSP quality is inconsistent and community documentation is full of gaps. But the cleanliness of the ISA itself and its extensibility make it well worth the investment. And once you get one board to boot, the next one goes much faster — I've seen it enough times to trust the pattern.

On my way home Friday, I passed by that back-alley dumpling shop again. Next week's lunch was already sorted.

Comments