DEV Community: Matt Miller

Remix Mini PC: Moving the Whole Operating System Onto the eMMC

Matt Miller — Sun, 24 May 2026 20:42:49 +0000

The previous post ended with a working cold boot. Plug in power, the BROM loads our TOC0 SPL from sector 16 of the SD card, our U-Boot runs, Armbian comes up to a login prompt. No laptop, no FEL, no manual intervention.

There was just one cosmetic issue. The SD card was still required.

If you pulled it out, the device fell straight to FEL because the BROM had nothing else to boot. That's not actually a problem in most usage, but it bothered me. The whole point of internal storage is that you don't need external media. A 16 GB eMMC is sitting right there on the mainboard, untouched since the project began, except for the small TOC0 SPL I had written to its boot partition during placement experiments and which the BROM had never accepted.

So: one more push. Move everything onto the eMMC, eject the SD card forever.

The unknown that wasn't

I had spent a long evening earlier in the project writing TOC0 SPLs to the eMMC's boot partition (/dev/mmcblk2boot0) at offset 0 and offset 0x2000, both with the same result every time: BROM silent, no SPL banner, device falls to FEL. I had concluded from this that "the eMMC boot partition is not the right place" — but I had never finished the obvious next experiment. I had never written a TOC0 SPL to the user area at sector 16, which is the exact offset that works on SD.

It is embarrassing how easy this was to test. From inside Armbian (booted from the SD as usual), with the boot partition's read-only flag still in its default state (we don't even need to unlock it because the user area is fully writable):

sudo dd if=~/uboot-build/u-boot/u-boot-sunxi-with-spl.bin \
        of=/dev/mmcblk2 bs=512 seek=16 conv=fsync

Power off. Pull the SD out. Plug power back in. Watch the UART.

U-Boot SPL 2026.07-rc2-g744cf5d4e398-dirty
DRAM: 2048 MiB
Trying to boot from MMC2
NOTICE:  BL31: ...
NOTICE:  BL31: Found U-Boot DTB at 0x20ad278, model: Remix Mini PC
...
=>

The BROM had just loaded our TOC0 SPL from the eMMC user area at sector 16, same offset as SD. The whole "the eMMC boot partition is the special boot device" mental model was wrong. Allwinner BROM on this device treats the eMMC user area and the SD card the same way — it scans them for a TOC0 signature at sector 16 and runs whatever it finds. The boot partitions are a separate eMMC feature the BROM does not use here.

The U-Boot prompt at the end is just because there is no Linux rootfs on the eMMC yet, so U-Boot has nothing to chain to. But the hard part — getting BROM to accept eMMC — was over the moment I tried the right offset.

The rootfs migration

Once the eMMC was a usable boot device, the remaining work was straightforward Linux administration. Create a partition on the eMMC user area starting at 16 MiB (well clear of the SPL at sector 16), format it ext4, rsync the SD's contents over, fix up the bootloader config to point at the new UUID.

sudo parted -s /dev/mmcblk2 mklabel msdos
sudo parted -s /dev/mmcblk2 mkpart primary ext4 16MiB 100%
sudo partprobe /dev/mmcblk2

Then immediately I learned something I had not known about parted. After running mklabel msdos, my TOC0 SPL at sector 16 was gone:

$ sudo dd if=/dev/mmcblk2 bs=512 skip=16 count=1 | hexdump -C | head -1
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00

Zeros. parted does not just write the 512-byte MBR at sector 0; it zeros some configurable amount of leading sectors to scrub residual filesystem signatures and old SPL data. The exact size depends on parted's version and the device, but on my install it was at least 8 KiB — which is exactly where my SPL lived.

This was completely recoverable — the SPL file was still on disk, one dd puts it back at sector 16 — but it's a real gotcha for anyone doing this in the same order I did. The right ordering is:

Create the partition table first with parted.
Then write the SPL at sector 16.
The partition itself starts at sector 32768, so nothing else touches sector 16 again.

After restoring the SPL and verifying, mkfs.ext4 -L armbi_emmc /dev/mmcblk2p1 formats the partition cleanly without touching the bootloader region. rsync -aHAXx / /mnt/emmc/ copies the current SD rootfs over while running on top of it. About 89,000 files and 2.1 GB. Nine minutes at SD-card-speed.

The variable substitution trap

Inside the eMMC copy, two files needed editing:

/etc/fstab — the kernel needs to know which device to mount as root.
/boot/armbianEnv.txt — the U-Boot boot script reads this to pass the root= parameter to the kernel.

Both currently referenced the SD card's UUID. They needed to reference the eMMC partition's UUID instead. Easy substitution, four shell commands:

SD_UUID=$(sudo blkid -s UUID -o value /dev/mmcblk0p1)
EMMC_UUID=$(sudo blkid -s UUID -o value /dev/mmcblk2p1)
sudo sed -i "s|$SD_UUID|$EMMC_UUID|g" /mnt/emmc/etc/fstab
sudo sed -i "s|$SD_UUID|$EMMC_UUID|g" /mnt/emmc/boot/armbianEnv.txt

I ran the first command. I skipped the second by accident — possibly the multi-line paste cut off, possibly I just didn't notice it. The third and fourth commands ran with $EMMC_UUID set to an empty string, and sed happily did exactly what I told it to: replace the SD UUID with nothing. The result was a fstab that read:

UUID= / ext4 defaults,noatime,...

and an armbianEnv.txt that read rootdev=UUID=. The eMMC rootfs would have failed to mount on boot in a way that would have been hard to debug at three in the morning.

The verify step — printing both files after the substitution — is what caught it. I noticed the UUID column was suddenly empty, looked at the variables, found $EMMC_UUID was unset, set it explicitly, ran a targeted sed to put the right UUID back. Twenty seconds of fix work because of a verify step that took ten seconds. Always print before and after.

The final test

After fixing fstab and armbianEnv, unmounting cleanly, and writing one last sync:

sudo poweroff

Unplug power. Pull SD card out (critical — the BROM tries SD first, and if it finds the SD's TOC0 SPL it'll boot from there regardless of whether the eMMC also has one). Plug power back in.

U-Boot SPL 2026.07-rc2-g744cf5d4e398-dirty
DRAM: 2048 MiB
Trying to boot from MMC2                          ← eMMC, not SD
NOTICE:  BL31: ...
NOTICE:  BL31: Found U-Boot DTB at 0x20ad278, model: Remix Mini PC

U-Boot 2026.07-rc2 Allwinner Technology
CPU:   Allwinner A64 (SUN50I)
Model: Remix Mini PC
DRAM:  2 GiB
...
MMC: no card present                              ← SD physically removed
...
switch to partitions #0, OK
mmc1(part 0) is current device
Scanning mmc 1:1...                               ← eMMC partition 1
Found U-Boot script /boot/boot.scr
...
Starting kernel ...

Armbian 24.11.1 Bookworm ttyS0

pine64 login:

 v24.11.1 for Pine64 running Armbian Linux 6.6.62-current-sunxi64
 Usage of /:  17% of 15G                          ← root mounted from eMMC

Full Armbian login. No SD card in the device. No laptop attached. The Remix Mini PC is now genuinely autonomous: plug in power, after about twenty seconds it is running Linux, ready to be SSH'd into or used directly through HDMI and a USB keyboard.

The boot trace is worth comparing to the previous post's. Same SPL build, same BL31, same U-Boot, same kernel, same rootfs — but the source has shifted from "SD card sector 16" to "eMMC user area sector 16." The SD card is no longer required for any part of the chain.

What this finishes

The original project goal — turn the device into something that boots its own operating system from its own internal storage without a host PC — is done. There is a small list of polish items left (the wired Ethernet is still off, the kernel-side device tree is still a patched BananaPi-M64 rather than a true Remix DTS, the eMMC could be using its boot partition more cleverly) but nothing on that list is blocking. The machine works.

The SD card, freshly imaged and gzip-backed-up at 893 MB, goes into a drawer as a recovery boot media. The two Remix Mini PCs on my desk — one with eMMC, one without — are both functional Linux SBCs as of this evening.

Lessons that I'd put on a sticky note

Test the obvious-but-untested case before getting deep into the non-obvious ones. Writing TOC0 to the eMMC user area at sector 16 — the same offset that works on SD — was the simplest possible experiment, and I never ran it until very late in the project. Hours of "the boot partition won't accept TOC0" investigation could have been compressed into one dd command.
parted mklabel zeros more than just the MBR. If you have anything in the first few kilobytes of a disk that you want to keep, write it after you create the partition table.
Empty shell variables make sed eat data. sed 's|X|$Y|g' with $Y unset does not error; it silently substitutes X with nothing. Always echo your variables before passing them to sed.
Verify steps are not optional. Every single bug in this project was caught by either a UART log or a "print the file after editing" command. Every single one was lost time when those verifies were skipped.

Three years between buying the device and getting it to boot on its own. About twenty seconds between power-on and login prompt now. That's the trade I would make again.

Enjoying the content? If you'd like to support my work and keep the ideas flowing, consider buying me a coffee! Your support means the world to me!

Remix Mini PC: The Same SD Card Boots the No-NAND Variant Too

Matt Miller — Sun, 24 May 2026 20:39:54 +0000

Source files: GitHub

A short coda to the last three posts.

I have a second Remix Mini PC on my desk. It looks identical to the first one — same case, same back panel, same ports — except the previous owner had removed the eMMC chip from the mainboard. No internal storage at all. For years I had assumed it was a separate problem to solve, that one day I would need to find a different recipe for the no-NAND variant.

After getting the first unit cold-booting from an SD card, I wondered: how much of the work is actually unit-specific, and how much is just "this is what an Allwinner H64 with secure boot wants"? The honest answer is, you cannot tell without trying.

So I pulled the SD card out of the working unit, unplugged the UART wires, and walked them across to the no-NAND machine. Wired everything back up — brown to GND, yellow to RX, orange to TX, leaving VCC unconnected, just like the original unit. Cleared the UART log on my laptop. Plugged in power.

The boot log that came back was, byte-for-byte, the same as on the unit with eMMC:

U-Boot SPL 2026.07-rc2-g744cf5d4e398-dirty
DRAM: 2048 MiB
Trying to boot from MMC1
NOTICE:  BL31: Detected Allwinner A64/H64/R18 SoC (1689)
NOTICE:  BL31: Found U-Boot DTB at 0x20ad278, model: Remix Mini PC

U-Boot 2026.07-rc2-g744cf5d4e398-dirty Allwinner Technology

CPU:   Allwinner A64 (SUN50I)
Model: Remix Mini PC
DRAM:  2 GiB
...
Starting kernel ...

Armbian 24.11.1 Bookworm ttyS0
pine64 login:

The TOC0 SPL was accepted by the BROM. DRAM training landed on the same 2 GiB. BL31 ran. U-Boot proper announced itself as "Model: Remix Mini PC." The Armbian kernel started. The login prompt appeared. The whole pipeline I described in the previous post worked, unchanged, on a board with one major chip physically absent.

What this tells me

A few things, all small but worth recording.

The recipe is the silicon, not the board. Once the BROM, the secure-boot fuse, and the DRAM controller are the same, the boot chain does not actually care whether eMMC is present. The Allwinner A64/H64 family has three MMC controllers as part of the SoC itself; U-Boot enumerates all three regardless of what is wired to them. The line

MMC:   mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1

prints identically on both units. The difference is only at scan time — mmc 2 finds an eMMC card on one unit and finds nothing on the other. The SD card on mmc 0 is the same on both.

One SD card revives any Remix Mini PC. That is a useful property for anyone trying this at home. You do not have to characterize the device in front of you to know which recipe applies. Make the SD card once, plug it into whatever Remix you have, power on.

The no-NAND unit is the better test bench. This is the practical consequence I will probably get the most use out of. The unit with eMMC carries years of accumulated bootloader state in its boot partitions; even after this project, those boot partitions still contain mixed eGON and TOC0 artifacts from my placement experiments. Anything I do to a no-NAND unit, by contrast, can never persist beyond power-off. Pull the SD card, plug a different SD card, fresh state. For experimenting with new U-Boot builds or DT changes, that is significantly safer.

No FEL is needed on either unit. This was the original goal — boot Linux from cold, no laptop attached, no USB sideload — and now it's true for both machines I have.

What this rules out

This post does not prove that the recipe works on every Remix Mini PC ever sold. There are likely small variations across production runs that I cannot test from here. The CPU stepping, the DDR3 supplier, the exact WiFi module — any of these could differ on someone else's unit and require small tweaks to the defconfig or DTB. The vqmmc-supply patch we did on the bananapi DTB, for example, is a Remix-specific addition; the DRAM clock and ZQ values in the upstream defconfig may not match every unit either.

What this post does prove is that the two units I have, despite one of them having a different hardware population, take the same SD card. That's a useful data point for anyone considering the recipe.

What I am keeping the no-NAND unit for

This used to be a paperweight. As of this evening, it is a perfectly good 2 GB ARM Linux box that boots from a single SD card and runs unattended. It will probably end up as a permanent home for something — a small monitoring node, a development sandbox for the next project, maybe just a second machine to keep on a shelf for friends who want to see the recipe work in person.

It is good to have the option.

Enjoying the content? If you'd like to support my work and keep the ideas flowing, consider buying me a coffee! Your support means the world to me!

Remix Mini PC: The Day It Finally Booted Itself

Matt Miller — Sun, 24 May 2026 20:37:04 +0000

Source files: GitHub

For more than a year, the Remix Mini PC on my desk could only be brought to life by attaching a laptop and pushing U-Boot into it over USB OTG. Every reboot was a manual ritual: trigger FEL mode, run sunxi-fel uboot ..., wait. Useful for development; useless as a real machine.

This is the post about the day that changed.

Recap: where we were

The previous post pinned down the wall. The Remix Mini PC has the Allwinner A64 "secure boot" eFuse burned, which makes the BROM refuse standard eGON-format SPLs from both the SD card and the eMMC. There is no ROTPK key fused in, so the BROM doesn't actually check who signed the boot code — it just demands the TOC0 wrapper format. A self-signed TOC0 image, signed with any RSA key, will pass.

That meant the path to a permanent boot was clear: produce a TOC0-wrapped SPL, write it to a place the BROM looks, power-cycle, see what happens.

Easy to write. Less easy to do.

The U-Boot defconfig that wasn't there

The mainline Linux kernel has had a device tree for the Remix Mini PC since 2023, contributed by Andre Przywara at Arm. The same author also submitted a four-patch series for U-Boot in April 2024 to add full board support, including a remix-mini-pc_defconfig with CONFIG_SPL_IMAGE_TYPE_SUNXI_TOC0=y — exactly the build switch that produces a TOC0 image.

Only some of that series actually landed in mainline U-Boot. The device tree file was imported. The defconfig and the Makefile glue were not. So a fresh clone of mainline U-Boot today has the DTS file sitting there, but no way to build it — no defconfig, and no entry in the dtb Makefile to compile it as part of any board build.

The defconfig is fourteen lines. The Makefile change is one line. Pulling the patch series from lore.kernel.org and extracting just patch 2/4 (which is the Remix-specific one) gave me both:

CONFIG_DEFAULT_DEVICE_TREE="sun50i-h64-remix-mini-pc"
CONFIG_SPL=y
CONFIG_MACH_SUN50I=y
CONFIG_DRAM_CLK=672
CONFIG_DRAM_ZQ=4013533
CONFIG_MMC_SUNXI_SLOT_EXTRA=2
CONFIG_SPL_IMAGE_TYPE_SUNXI_TOC0=y
CONFIG_SUPPORT_EMMC_BOOT=y
...

git am rejected the patch because the surrounding context in arch/arm/dts/Makefile had drifted in the two years since the patch was written. So I applied both halves by hand: created the defconfig file directly from the patch's + lines, and used a small awk to splice the new DTB filename into the right place in the Makefile.

That part went smoothly. The rest of the day did not.

TF-A is a black hole

The U-Boot build needs ARM Trusted Firmware-A (bl31.bin) as the EL3 secure monitor. Standard sunxi64 build step: clone TF-A, make PLAT=sun50i_a64 bl31, point U-Boot at the output.

TF-A's build did not cooperate. The first attempt failed because I built it with DEBUG=1 and the resulting binary was 472 bytes too big for the A64's BL31 SRAM region. Fine, build release. Release said make: Nothing to be done for 'bl31', even after a clean clone in a brand-new directory.

I spent an embarrassing amount of time on this. The cause turned out to be a name collision: TF-A has both a bl31 makefile target and a bl31/ source directory in the root of the repo. GNU make sometimes interprets make bl31 as "build the directory bl31/," sees that the directory exists, and concludes there is nothing to do. make -B didn't override it. make all didn't produce a bl31. Neither did invoking the absolute path of the output file as a target.

After about half an hour, I gave up and searched Debian for a pre-built one:

$ dpkg -L arm-trusted-firmware | grep sun50i
/usr/lib/arm-trusted-firmware/sun50i_a64
/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin

There it was. Debian's arm-trusted-firmware package ships pre-built BL31 binaries for many platforms, including sun50i_a64. The version is older than what U-Boot's bleeding-edge build would normally use (TF-A 2.8 from 2022 vs. master), but for our purposes — getting the secure monitor up and getting out of EL3 — it works fine.

$ export BL31=/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin
$ cd ~/uboot-build/u-boot && make -j4

The build needed one more thing it had been complaining about earlier: a signing key. TOC0 images are signed; mkimage looks for root_key.pem in the build directory. The error message even tells you the cure:

mkimage (TOC0): info: Try 'openssl genrsa -out root_key.pem'

Since the BROM does not check the key against a fused root-of-trust hash, any RSA key works. I generated a 2048-bit one on the spot. Reproducible enough — just keep the file around.

The build finished. The first eight bytes of u-boot-sunxi-with-spl.bin were:

54 4f 43 30 2e 47 4c 48   |TOC0.GLH|

Right magic. Worth trying.

The placement experiments

The eMMC's boot partition was the obvious target. PARTITION_CONFIG was already set to 0x48 — boot from boot partition 1 — so writing the new SPL to /dev/mmcblk2boot0 at offset 0 should have been the cleanest possible test.

Wrote it, power-cycled, watched the UART. Silence. The green LED came on, the BROM accepted no boot code, the device sat in FEL mode waiting for a USB sideload. Same outcome that I had been fighting for a year.

Tried offset 8 KiB instead — that's where sunxi SPL lives on SD cards. Same silence. (I also discovered that Linux re-applies the eMMC boot partition's read-only flag on every boot, so my "second" write had silently failed. That cost another ten minutes of confusion before I caught the Operation not permitted in the dd output.)

The thing that finally worked was the most embarrassing one: write the same TOC0 to the SD card at sector 16, the standard sunxi SD SPL offset.

$ sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblk0 bs=512 seek=16 conv=fsync

Pull power. Plug power. Watch the UART.

U-Boot SPL 2026.07-rc2-g744cf5d4e398-dirty (May 22 2026 - 22:23:12 +0200)
DRAM: 2048 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.8(release):
NOTICE:  BL31: Detected Allwinner A64/H64/R18 SoC (1689)
NOTICE:  BL31: Found U-Boot DTB at 0x20ad278, model: Remix Mini PC

U-Boot 2026.07-rc2-g744cf5d4e398-dirty Allwinner Technology

CPU:   Allwinner A64 (SUN50I)
Model: Remix Mini PC
DRAM:  2 GiB

The one line that meant everything: Model: Remix Mini PC. For more than a year, every boot of this device — when it booted at all — had announced itself as a BananaPi-M64, because that was the closest mainline U-Boot defconfig I could compile. This time, for the first time, U-Boot reported the device's actual name. The BROM had loaded my self-signed TOC0. The secure boot wall was a key the device was willing to copy off itself.

The last small obstacle

U-Boot kept going and tried to boot Linux, but failed:

File /boot/dtb/allwinner/sun50i-h64-remix-mini-pc.dtb does not exists

The new defconfig sets CONFIG_DEFAULT_DEVICE_TREE="sun50i-h64-remix-mini-pc", so when U-Boot's boot script asks the SD card for a kernel device tree, it asks for that filename — but the Armbian image on the card was built for sun50i-a64-bananapi-m64 and doesn't ship the Remix DTB.

A two-line fix. Mount the SD card on my laptop, append fdtfile=allwinner/sun50i-a64-bananapi-m64.dtb to armbianEnv.txt, copy the newly-built remix DTB to /boot/dtb/allwinner/ as a fallback. Reinsert.

Power-cycle. Without touching the laptop afterwards. The SPL banner scrolled, U-Boot loaded, the boot script ran, the kernel started, Armbian came up, the login prompt appeared.

Plug power, it runs.

What this looks like now

The Remix Mini PC is no longer a glorified paperweight. The boot chain is entirely my own:

silicon BROM
  -> SD sector 16:    TOC0-signed U-Boot SPL (mainline U-Boot, signed with my key)
     -> BL31:         Debian's pre-built TF-A 2.8 for sun50i_a64
        -> U-Boot:    mainline 2026.07-rc2 with remix-mini-pc_defconfig
           -> /boot/boot.scr -> Image + initrd + bananapi-m64 DTB (with my vqmmc patch)
              -> Linux 6.6.62 -> Armbian login

No laptop. No FEL. No magic. Just power.

There are still loose ends. The Linux side is still using a patched BananaPi-M64 device tree rather than the proper Remix one, because that is what the Armbian kernel package has prebuilt and I have not built a kernel against the upstream Remix DTS yet. The eMMC is unused — the boot chain lives on the SD card, because that is where the BROM is willing to read TOC0. I can probably get the eMMC into the boot path too, but it is no longer urgent now that the device just works.

Reflections

A few things from the journey worth holding onto.

The wiki was right and I should have believed it sooner. The linux-sunxi page for this device says, almost in passing, "the SoC has the secure boot fuse burned, so it will not accept any standard eGON boot media." I read that line a year ago and assumed it was something esoteric and untestable. It was the single most important fact about the device.

Half-merged upstream support is more common than you would think. The DTS file for this device sits in mainline Linux and in mainline U-Boot, but the U-Boot defconfig that ties it together never landed. It is one small patch file on a mailing list, easy to apply by hand once you find it. If you are reviving an obscure SBC, search the mailing list archives before assuming you have to write everything yourself.

Old tools are sometimes still right. I spent an hour fighting TF-A's build system trying to produce a fresh BL31 binary. The bl31 that ended up being executed is a 2022 build from a Debian package, and the device booted with it the first time I tried. Doing the unfashionable thing was the fastest path.

The diagnostic that mattered was the UART line. Once I could see "Model: Remix Mini PC" instead of "BananaPi-M64," I knew exactly what I had done — and what to fix next. Every interesting debugging moment in this project has happened over a serial cable. Buy the cable.

This was the last big wall. Whatever comes next on this device is application work, not survival work. After more than a year, that feels different in a way that is hard to write down.

The Remix Mini PC is alive on its own.

Enjoying the content? If you'd like to support my work and keep the ideas flowing, consider buying me a coffee! Your support means the world to me!

Remix Mini PC: Confirming What Stands Between Us and Cold Boot

Matt Miller — Sun, 24 May 2026 20:34:40 +0000

Source files: GitHub

Now that the eMMC is finally accessible — see the previous post — the project's centre of gravity shifts. The remaining goal is to make the device boot Linux from cold, without needing a USB FEL sideload every time. This post is about a small, quick experiment that pinned down exactly what is in the way.

What we knew

The Allwinner A64 BROM (the immutable mask-ROM in the SoC) tries to find an SPL in this order:

SD card (mmc0)
eMMC (mmc2)
SPI NOR flash
FEL mode over USB OTG

Up until now my workflow has always been to enter FEL mode and sideload U-Boot from the laptop. That works. But it means the device cannot run headless and standalone — every reboot needs the laptop.

The Linux-sunxi wiki page for the Remix Mini PC has a paragraph that I had read but not really believed:

The SoC has the "secure boot" fuse burned, so it will not accept any standard eGON boot media on an SD card or eMMC, and instead it expects TOC0 wrapped boot code.

"eGON" is the magic header on standard sunxi SPLs; "TOC0" is a signed-image format with a header structure derived from ARM's Trusted Firmware. The wiki is saying the BROM will refuse anything in the older eGON format.

That sounded inconvenient enough that I wanted to be sure it was true on my specific unit before doing any work that depended on it. Two minutes of testing can save hours of building.

The experiment

The test is trivial:

Boot Armbian normally (via FEL+sideload, as always).
From inside Armbian, run sudo poweroff and wait for a clean shutdown.
Unplug power.
Plug power back in. Do nothing else — no FEL trigger, no sunxi-fel command, no key on a keyboard.
Watch the UART for any sign of life.

If the BROM accepts the SPL on the SD card or the eMMC, U-Boot will start printing within a second or two. If it does not, the device will sit silent — the BROM falls back to FEL mode but FEL mode itself is silent until something talks to it over the OTG port.

I set the SD card to be inserted with a known-working eGON-format SPL on it (the Armbian image's standard layout, dd'd to sector 16). The eMMC boot partition also has an eGON SPL from previous experimentation. If secure boot were not enforced, one of the two should have worked.

What happened

The power LED came up green. UART stayed completely silent. After fifteen seconds I checked the USB side:

$ lsusb | grep -i allwinner
Bus 001 Device 010: ID 1f3a:efe8 Allwinner Technology sunxi SoC OTG connector in FEL/flashing mode

The board is alive — it is sitting in FEL mode, waiting for a sideload — but it has rejected both candidate SPLs. That is the textbook fingerprint of a BROM with the secure boot eFuse burned and no eGON path accepted.

For completeness, there is no ROTPK (root-of-trust public key) burned into the chip's eFuses either. That second fact matters: it means the BROM enforces the format (TOC0) but does not enforce a particular signing key. Anyone can sign with any key and the BROM will load it. The TOC0 wrapper is a structural requirement, not a cryptographic one.

What this rules out, and what it leaves

There were two obvious quick-wins I had been considering for cold-boot, and this test rules out both:

Option B: zero the existing eMMC SPL and let the BROM fall through to SD.
The hope here was that the eMMC SPL is what is being chosen first, and if we corrupted it the BROM would skip eMMC and use the SD card's SPL instead. The test shows the SD SPL is also being rejected — both are eGON-format, and both fail the BROM's check. Zeroing the eMMC SPL changes nothing.

Just trusting that eMMC-boot already works because there is an eGON SPL on the eMMC boot partition.
Looking at the eMMC dump from the previous session, /dev/mmcblk2boot0 already contained an eGON-format SPL (with a header identifying it as a sunxi mainline build). I had briefly hoped this meant the device might already cold-boot from eMMC. It does not. Same rejection.

What is left, and the only real path forward, is to produce a TOC0-wrapped SPL and write it to either the SD card's sector 16 or the eMMC's boot partition. The mainline U-Boot tree has a defconfig — remix-mini-pc_defconfig, added by Andre Przywara — that does exactly this. Build it, sign with any key, write it down, cold-boot.

A small but useful negative result

The whole exercise took less time than my coffee took to cool down, but it changed the shape of the next chunk of work. Without it I would have been tempted to do something destructive to the eMMC for no benefit. With it I know:

TOC0 is mandatory. There is no eGON cold-boot path.
Both the SD and the eMMC are dead ends for standard sunxi binaries — the medium is fine, the format is the problem.
FEL remains the only entry point until the day a TOC0-wrapped SPL lives on the device.
Once we have a working TOC0 SPL, putting it on either the SD card or the eMMC boot partition should produce a working cold-boot. We have two independent shots.

What's next

Next session: clone mainline U-Boot, build remix-mini-pc_defconfig, write the resulting SPL to the eMMC, power-cycle without a laptop attached, and — if the wiki is to be believed — watch the device finally come up on its own.

Enjoying the content? If you'd like to support my work and keep the ideas flowing, consider buying me a coffee! Your support means the world to me!

Remix Mini PC: After a Year of Dead Ends, the eMMC Finally Talks

Matt Miller — Sun, 24 May 2026 20:28:55 +0000

Source files: GitHub

For more than a year I have been chasing the same brick wall on the Remix Mini PC project: I could sideload a working Linux from an SD card, but the internal eMMC was a black box. Every attempt to read from it returned an I/O error. Every theory I tried — write-protect bits, NAND blacklists, hardware reset quirks, lockout states left behind by Android — went nowhere.

It turns out the cause was none of those things. It was one missing line in a device tree.

The setup recap

The Remix Mini PC is a 2015-vintage Android desktop box built around an Allwinner SoC (marketed as "H64", which is the same silicon as the much more common A64). Stock firmware was a locked Android variant that the manufacturer abandoned long ago. The project's goal: replace it with Armbian, permanently, on the internal eMMC.

The state going into this session:

FEL mode sideload of mainline U-Boot works (built with the BananaPi-M64 defconfig).
SD card boot all the way to a login prompt works (Armbian 24.11.1, kernel 6.6.62).
Reading from the internal eMMC, however, immediately fails with kernel errors:

sunxi-mmc 1c11000.mmc: data error, sending stop command
sunxi-mmc 1c11000.mmc: send stop command failed
mmc2: cache flush error -110
mmc2: tried to HW reset card, got error -110
mmcblk2: recovery failed!

The kernel sees the chip — it reads its CID, its CSD, its 14.6 GiB capacity, its part name (AGND3R) — but the moment the host asks for actual data, the bus collapses.

Things I tried that did not matter

I went deep into the device tree binary. Patching it in place with fdtput, decompiling and recompiling with dtc. I tested, in order:

Knob	What I tried	Result
Bus clock	150 MHz → 25 MHz → 1 MHz	identical failure
Bus modes	disabled HS200, HS400, 1.8V signaling	identical failure
Bus width	8-bit → 4-bit	identical failure
HW reset capability	removed `cap-mmc-hw-reset`	identical failure
Pin muxing	dropped the HS400 data-strobe pin	identical failure

The failure mode never changed shape. That was the clue I should have read earlier: if signal-rate tweaks don't move the needle at all, the problem is not at the signal layer.

The breakthrough

A web search turned up something I had not realised existed: the Remix Mini PC is supported in mainline Linux, under the name sun50i-h64-remix-mini-pc.dts, contributed by Andre Przywara at ARM. The DTS lives in the mainline kernel tree at arch/arm64/boot/dts/allwinner/. The corresponding U-Boot patch landed in April 2024.

I pulled the official Remix DTS and put it side by side with the BananaPi-M64 DTS I had been using. The difference for the eMMC block jumped off the screen:

&mmc2 {
    pinctrl-names = "default";
    pinctrl-0 = <&mmc2_pins>, <&mmc2_ds_pin>;
    vmmc-supply = <&reg_dcdc1>;     // chip Vcc, 3.3V — was present
    vqmmc-supply = <&reg_eldo1>;    // I/O voltage, 1.8V — WAS MISSING
    bus-width = <8>;
    non-removable;
    mmc-hs200-1_8v;
    mmc-hs400-1_8v;
    cap-mmc-hw-reset;
};

The BananaPi-M64 DTB declares only vmmc-supply, the regulator that powers the eMMC chip itself. It says nothing about vqmmc-supply, the separate regulator that drives the eMMC bus signal lines.

eMMC uses two voltage domains. Vcc (the vmmc rail) powers the chip's internal logic. VccQ (the vqmmc rail) is the I/O voltage for CLK, CMD, and DAT0–7. On the Remix's PCB, that rail is wired to a different regulator (eldo1, 1.8V) than the chip's main supply. Without the kernel knowing about that regulator, it never gets enabled — and the data bus lines have no drive voltage.

That explained everything. The chip's command/response channel runs at different signaling and was already powered, so initialisation worked. The instant the host attempted a data transfer over DAT0–3, the bus collapsed. There was nothing to receive on.

The fix

I added the missing property to the live DTB on the SD card:

sudo fdtput -t i /boot/dtb/allwinner/sun50i-a64-bananapi-m64.dtb \
    /soc/mmc@1c11000 vqmmc-supply 0x4e

0x4e is the phandle of the eldo1 regulator node in the same DTB, which the BananaPi-M64 board uses for its audio codec but which on the Remix is the eMMC I/O rail. Same regulator hardware; just being repurposed to point at the right consumer.

Reboot. Sideload U-Boot via FEL. Log in. Type the test:

sudo dd if=/dev/mmcblk2 bs=1M count=1 of=/tmp/test.bin status=progress

1+0 records in
1+0 records out
1048576 bytes (1,0 MB, 1,0 MiB) copied, 0,0482 s, 21,7 MB/s

A megabyte. In fifty milliseconds. From a chip that had not yielded a single readable byte in over a year.

For good measure I queried the EXT_CSD register, which uses a different MMC command path than block reads — that worked too. And it revealed something I had not let myself hope for:

BOOT_WP_STATUS:   0x00      // not write-protected
BOOT_WP:          0x00      // not write-protected
USER_WP:          0x00      // not write-protected
BOOT_CONFIG_PROT: 0x00      // boot config can be changed
PARTITION_SETTING_COMPLETED: 0x00

The chip is not locked. It has never been locked. The "permanently write-protected" story I had been telling myself based on Linux-level force_ro flags and observed I/O errors was wrong. The chip is wide open. I just could not see it because the bus could not carry a single byte.

Lessons I want to keep

A few things from this session worth holding onto, in case they are useful to anyone else fighting a similar ghost.

Find the official upstream description of your hardware before you start guessing at it. The single most valuable artifact in this debugging session was the official sun50i-h64-remix-mini-pc.dts file in mainline. Fifteen minutes of reading saved me what would have been days more of DT poking. The fact that the Remix Mini PC has had mainline support since 2023 and I did not know it is on me.

If a tunable does not change the failure mode, the failure is not in that tunable's layer. I tried five different knobs across two orders of magnitude in clock speed. None of them moved the symptom. That should have told me immediately that the failure was at a layer below "bus signaling". I kept going because I had no better idea, but in hindsight that was wasted effort.

Distinguish what the chip says about itself from what the host's view of the chip says. Linux block-device flags like force_ro are software-level safety overlays. The chip's actual write protection lives in the EXT_CSD register and is queryable with mmc-utils. Until I could query that register, every claim about whether the chip was "locked" was guesswork. The reason I could not query it earlier was the same vqmmc problem — mmc extcsd read also needs a working data bus. The same fix unlocked everything at once.

Two voltage rails. eMMC always has two voltage rails. Vcc and VccQ. If you only configure one, the chip will enumerate and then silently refuse all data transfers. This is now permanently lodged in my head.

What is next

The eMMC being readable is the milestone, but the project's goal is to make the Remix boot Linux from internal storage without needing a USB-OTG FEL trigger every time. That is a separate problem — the Allwinner A64 boot ROM on this board enforces a particular signed-image format called TOC0, which standard sunxi U-Boot does not produce by default. There is a mainline U-Boot defconfig (remix-mini-pc_defconfig) that does, and writing a TOC0-wrapped SPL into the eMMC boot partition should give us a cold-boot path.

That's the next post.

For now: after more than a year, the device that I had been treating as half-dead has its biggest organ back. Onward.

Enjoying the content? If you'd like to support my work and keep the ideas flowing, consider buying me a coffee! Your support means the world to me!

Bridging Both Worlds: Can You Mix Native and Frameworks?

Matt Miller — Wed, 23 Apr 2025 08:40:00 +0000

Introduction

Why choose one side when you can get the best of both?

Today’s tools let us blend native performance with framework convenience—without forcing a binary choice.

From Rust-powered backends for React frontends, to WebAssembly running C++ in the browser, this is the era of hybrid stacks. Let's explore how developers are bridging native and modern frameworks in real-world projects.

1️⃣ The Case for Hybrid Architectures

Modern apps often have diverse needs:

Speed in the backend
Interactivity in the frontend
Hardware control with cross-platform UI
Offline capabilities with cloud syncing

No single language or framework can do all of that efficiently.

That’s where mixing comes in.

2️⃣ Examples of Native + Framework Blends

💻 Tauri + React/Svelte

Frontend: React or Svelte
Backend: Rust
Result: A tiny desktop app (3–10 MB!) with full system access

✅ Tauri is a lean, secure alternative to Electron

✅ You get web dev DX + Rust performance

✅ Ships to Windows, macOS, Linux

🔹 Use case: cross-platform apps that need to interact with files, devices, or the OS

🌐 WebAssembly (WASM) + JS Frameworks

Write critical logic in C/C++, Rust, or Go
Compile to WASM
Load it into Vue, React, or Angular

✅ Speed boost where JS is too slow

✅ Perfect for:

Image/video processing
Cryptography
Emulator-based apps
Math-heavy calculations

💡 Tools: wasm-bindgen, Emscripten, wasm-pack

⚙️ Rust or Go Backends + Frontend Frameworks

Rust (Actix, Axum) or Go (Gin, Fiber) for backend API
React/Next.js or Vue/Nuxt for frontend
Type-safe, scalable, and secure

🔹 Use case: High-performance APIs for dashboards, apps, SaaS

✅ Clean separation of concerns

✅ Native speed, framework interactivity

✅ Modern DX with strong compile-time checks

3️⃣ Why Hybrid Is Gaining Popularity

🟢 Benefits:

Performance where it counts, convenience where it doesn’t
Gradual adoption—you can keep your frontend and rewrite the backend piece by piece
Best tool for each job, not just one hammer

🔴 Challenges:

More complex setup (especially if teams are split)
Build pipelines need to handle multiple toolchains
Debugging across the boundary (e.g., WASM + JS) can be tricky

💡 But modern tools (like Vite, Tauri, Deno, Docker, and wasm-pack) make this surprisingly smooth.

4️⃣ Real-World Hybrid Examples

🔹 Figma – Web frontend + native WASM rendering engine

🔹 Tauri-based apps – Productivity tools, note apps, crypto wallets

🔹 Photopea – Photoshop-like app entirely in browser, with native-powered logic via WASM

🔹 VS Code – Electron frontend + native Node + Rust-based extensions

5️⃣ Tips for Making the Blend Work

Clearly define roles between native and framework layers
Use shared types if possible (e.g., TypeScript + Rust typegen)
Build with automation—make your CI/CD handle both environments
Start with core logic in native, then expose to UI as a service/module

💡 Final Thoughts: Don’t Choose—Combine

✔ You don’t have to pick frameworks OR native

✔ In 2025, the real skill is knowing how to connect systems

✔ Use native power where needed (performance, hardware, security)

✔ Use frameworks for rapid UI, dev velocity, and collaboration

💬 Your Thoughts?

Have you built a hybrid project? Or thought about mixing Rust or Go with your favorite frontend stack? Let’s share ideas in the comments!

Enjoying the content? If you'd like to support my work and keep the ideas flowing, consider buying me a coffee! Your support means the world to me!

Build Time, Maintenance & Team Dynamics: Beyond the Code

Matt Miller — Tue, 22 Apr 2025 08:40:00 +0000

Introduction

It’s easy to get caught up in syntax, benchmarks, or feature sets—but let’s zoom out. The true test of any tech stack isn’t just how fast it runs or how cool it is, it’s how well it holds up over time, especially when real people work on it together.

In this post, we’ll look at how build complexity, maintainability, onboarding, and team workflows differ between native-first projects and framework-based ones.

1️⃣ Build Time: From Source to Something You Can Use

🧱 Native Stacks (Rust, C++, Go)

✅ Powerful, but require:

Compilers and toolchains (e.g., Cargo, Make, GCC, Clang)
Managing linker flags, build targets, dependencies
Cross-compilation setups for Windows/macOS/Linux

💡 Build times can be long, especially in large C++ codebases. Rust has improved this with incremental builds, but still slower than scripting languages.

⚙️ Framework Stacks (JS, Python, PHP, etc.)

✅ Usually interpreted or transpiled

✅ Easier to get running:

npm install && npm run dev
python app.py

💡 You often get faster feedback loops during dev, especially with hot reload or live updates.

🔥 Reality Check:

Metric	Native Projects	Framework Projects
First-time setup	Medium/Hard	Easy/Instant
Compile times	Long (C++), Moderate (Rust)	Instant/short (TS/Python)
Tooling complexity	Higher	Lower
CI/CD integration	More config-heavy	Smoother (out of the box)

2️⃣ Maintenance Over Time

Native code tends to be more durable, but also harder to modify.

Native:

Strong type systems and low-level control = less technical debt
But changes often affect more parts of the system
Legacy C++ or embedded code can feel like a maze
Rust’s compiler fights for correctness (which helps future you)

Framework:

Easy to get started, but hard to keep clean
Popular frameworks shift fast—React, Angular, Vue, etc.
Can accumulate "magic" abstractions and outdated patterns
Refactoring is easier, unless you're buried in third-party dependencies

💡 Long-term success = clear architecture, tests, and documentation, no matter what stack you choose.

3️⃣ Onboarding New Developers

This is where frameworks often shine.

⚙️ Framework Projects:

✅ Easy to get up and running

✅ Clear conventions (routes, components, folder structure)

✅ Tons of tutorials and guides

🟡 Downside: Developers may not understand underlying behavior, leading to misuse of abstractions.

🧱 Native Projects:

🟠 Steeper learning curve

🟠 Devs need to understand memory, pointers, types, or concurrency primitives

🟠 Tooling/setup may be unfamiliar (especially outside web developers)

✅ But once they’re onboarded, native systems tend to be more predictable and robust

💡 Tradeoff: Shorter ramp-up with frameworks, longer ramp-up but stronger foundations with native.

4️⃣ Team Collaboration & Scaling

Category	Native Codebases	Framework-Based Projects
Collaboration Clarity	Enforced by strict typing	Often depends on discipline
Tooling Standardization	Fragmented by OS, compiler	Mostly unified via NPM/Pip/etc.
Code Reviews	Harder, but more precise	Easier, but often surface-level
Scaling Dev Teams	Better for core systems	Better for fast-moving feature teams

💡 The bigger your team and codebase, the more you need structure. Whether native or framework-based, introduce linting, testing, CI, and style guides early.

5️⃣ Who Maintains What? DevOps & Tooling Support

Native:

Often requires custom build environments
Monitoring, logging, deployment tools may be more manual
DevOps must know cross-compilation, packaging, and binary signing

Framework:

Ready-to-go platforms: Vercel, Netlify, Heroku
One-click deploy pipelines
Simple Dockerization or serverless options
Easy integration with modern tools like Sentry, Datadog, Supabase, Firebase

💡 Native is powerful for infra/OS teams. Frameworks are powerful for product teams.

💡 Final Thoughts: It’s Not Just About the Code

✔ Developer experience affects team morale, velocity, and quality

✔ Native stacks may need more setup, but they age well

✔ Frameworks let teams ship fast, but can become brittle without discipline

✔ Invest in documentation, conventions, automation, and CI/CD—regardless of language

💬 Your Thoughts?

Which part of team collaboration or long-term maintenance hits hardest in your projects? Let’s talk in the comments!

Enjoying the content? If you'd like to support my work and keep the ideas flowing, consider buying me a coffee! Your support means the world to me!

Use Case Matchups: Native vs Framework by Project Type

Matt Miller — Mon, 21 Apr 2025 08:40:00 +0000

Introduction

There’s no single “best” tool for all jobs, but there are better tools for specific jobs.

So instead of asking "Should I go native or use a framework?", a smarter question is:

"What am I building, and which approach fits that use case best?"

In this post, we’ll compare real-world project types—mobile apps, CLI tools, backends, embedded projects, and more—and match them against the native vs framework landscape.

1️⃣ Mobile Apps

📱 Option A: Native (Swift for iOS / Kotlin for Android)

✅ Full access to camera, sensors, Bluetooth, OS features

✅ Best performance

✅ Native UI = best look & feel

❌ Double the codebase (iOS + Android)

❌ Slower dev cycle

🌐 Option B: Cross-Platform Frameworks (Flutter, React Native)

✅ Write once, run everywhere

✅ Big ecosystem

✅ Faster MVPs, faster iteration

❌ May feel “non-native” in edge cases

❌ Slower access to new OS features

🔥 Verdict:

Use native for long-term, high-performance apps.

Use frameworks for MVPs, startups, or fast cross-platform delivery.

2️⃣ CLI Tools

🧱 Option A: Native (Rust, Go, C++)

✅ Tiny, fast binaries

✅ No runtime or install dependencies

✅ Runs on almost anything (great for DevOps)

❌ Slightly steeper learning curve

❌ Less dynamic UX

⚙️ Option B: Frameworks (Node.js + oclif / Python + Click)

✅ Easy to write

✅ Faster prototyping

✅ Tons of NPM/PyPI packages available

❌ Slower runtime

❌ Requires interpreter or runtime installed

🔥 Verdict:

Use native when performance or distribution matters.

Use frameworks for internal scripts, tools, or one-off automation.

3️⃣ Backend APIs & Microservices

⚡ Option A: Native (Go, Rust, Java)

✅ High-performance, great concurrency

✅ Lightweight microservices

✅ Ideal for large-scale backends

❌ More verbose to build

❌ Harder to iterate quickly

🧩 Option B: Frameworks (Express, FastAPI, Laravel, NestJS)

✅ Rapid development

✅ Built-in auth, routing, ORM

✅ Great DX

❌ May not scale as efficiently

❌ Higher memory usage

🔥 Verdict:

Use native for performance-critical APIs or infra tools.

Use frameworks for most web apps, admin dashboards, and MVPs.

4️⃣ Embedded & IoT

⚙️ Option A: Native (C, C++, Rust)

✅ Full hardware control

✅ Small binary sizes

✅ No overhead

❌ Manual memory management (except Rust)

❌ Long dev cycles

🧠 Option B: Frameworks (MicroPython, Johnny-Five + JS)

✅ Easy to get started

✅ Great for education, prototyping

❌ Limited in speed & precision

❌ Not suitable for production hardware

🔥 Verdict:

Native is the king for embedded.

Frameworks = good for early experimentation or teaching.

5️⃣ Desktop Apps

💻 Option A: Native (C++, Swift, Rust)

✅ Best performance, native feel

✅ Full access to system APIs

✅ No browser dependency

❌ Platform-specific maintenance

❌ Slower development

🌍 Option B: Frameworks (Electron, Tauri, Flutter)

✅ One codebase = all platforms

✅ Leverages web tech

✅ Easy packaging and updates

❌ Electron = large binaries, RAM hungry

❌ UX trade-offs

🔥 Verdict:

Use native or Tauri for lightweight, efficient tools.

Use Electron or Flutter for fast delivery or cross-platform GUI apps.

6️⃣ Web Frontends (Bonus)

🧠 Option A: Vanilla JS/TS

✅ Smallest bundle

✅ No dependency bloat

✅ Full control

❌ Slower to build from scratch

❌ More setup, more manual wiring

⚙️ Option B: Frameworks (React, Svelte, Vue, etc.)

✅ Component systems, routers, state mgmt

✅ Huge ecosystems

✅ Best for teams

❌ Abstraction overhead

❌ Bigger bundles by default

🔥 Verdict:

Use vanilla for small/static projects or learning.

Use frameworks for anything interactive, team-based, or scale-ready.

💡 Final Thoughts: Choose Based on Fit, Not Hype

✔ Frameworks are great for speed, flexibility, and starting fast

✔ Native is unbeatable when you need control, speed, and precision

✔ Always ask: "What am I building? Who’s using it? How will it grow?"

💬 Your Thoughts?

Have you ever picked the wrong tech for a project? What’s your favorite use-case combo? Let’s chat in the comments!

Enjoying the content? If you'd like to support my work and keep the ideas flowing, consider buying me a coffee! Your support means the world to me!

The Framework Appeal: Abstraction, Speed & Dev Experience

Matt Miller — Fri, 18 Apr 2025 08:40:00 +0000

Introduction

While native languages give you raw power, frameworks are built for momentum. They abstract away the low-level stuff and let you ship faster, focus on features, and avoid reinventing the wheel.

But what's the real cost of using a framework?

Are you trading control for convenience? Speed for productivity?

Let’s unpack the real reasons devs love frameworks—and the hidden trade-offs you may not realize until later.

1️⃣ Why Developers (Still) Love Frameworks

✅ Rapid Development

Frameworks let you:

Spin up projects in minutes
Skip boilerplate
Get to "business logic" faster

🔹 React, Vue, Svelte → Handle UI state, routing, rendering

🔹 Django, Rails, Laravel → Give you ORM, auth, migrations, templating out of the box

🔹 NestJS, FastAPI, Spring Boot → Offer structure + flexibility in backend systems

✅ Developer Experience (DX)

Frameworks often come with:

Dev servers with hot reload
CLI tools and generators
Convention-based routing
Built-in testing, linting, bundling

💡 These things don’t make your app better, but they make your dev life better—especially in a team.

✅ Community & Ecosystem

Popular frameworks have:

Tons of libraries and plugins
Rich documentation and examples
Answers on Stack Overflow
Community support

🔹 React + Tailwind + Next.js? You’ll find a tutorial for that.

🔹 Django + Celery + Redis? There’s a whole ecosystem around it.

📌 The more popular the framework, the faster you can solve problems—without having to become an expert in every subsystem.

2️⃣ The Real Cost of Frameworks

❌ Abstraction = Blind Spots

The more a framework does for you, the less you understand about what’s actually happening.

📌 You might know how to use .map() in React, but not how the virtual DOM diffing works.

📌 You might deploy with Django’s ORM, but never learn how SQL joins really behave.

This makes debugging harder—especially when something breaks outside the happy path.

❌ Performance Overhead

Frameworks add layers—routing, component trees, reflection, decorators…

This can lead to:

Slower boot times
Larger bundles
Memory bloat
Event handler sprawl

🔹 Example: React apps with 50+ components and 1MB+ of JavaScript before rendering anything.

📌 Native apps and minimal libraries usually outperform bloated framework stacks.

❌ Dependency Hell & Framework Lock-In

The more you depend on framework-specific tools:

The harder it is to migrate away
The more painful updates become
The more you have to trust third-party maintainers

💥 One breaking change or deprecated package can cost hours (or days) of rework.

3️⃣ Frameworks Shine in the Right Context

Let’s be fair—frameworks aren’t bad. They just need to fit the project size, team experience, and long-term goals.

🔹 Great Use Cases for Frameworks:

MVPs and prototyping
SaaS dashboards and admin panels
Internal tools
Rapid iteration with small teams

🔸 When to Be Cautious:

Low-level performance needs (e.g., game dev, real-time tools)
Complex edge cases where framework abstractions fight your logic
Large-scale projects with long lifespans and multiple teams

4️⃣ Frameworks Keep Evolving

Frameworks aren’t static—many are trying to reduce their own complexity.

Modern trends:

Svelte → compiles away at build time
Qwik → resumes instead of rehydrating
HTMX → goes back to basics with HTML-over-the-wire
Fresh (Deno) and SolidJS → prioritize minimalism and DX

📌 The ecosystem is responding to its own bloat—and trying to bring us closer to the metal again.

💡 Final Thoughts: Frameworks Are Power Tools—Use Them Wisely

✔ Frameworks are amazing for speed, productivity, and collaboration

✔ But they come with abstraction, overhead, and long-term baggage

✔ Know what’s under the hood, so you’re not helpless when things break

✔ Choose frameworks that fit the project, not just the hype

💬 Your Thoughts?

What’s your go-to framework? Have you ever hit the limits of one and regretted it? Let’s share war stories in the comments!

Enjoying the content? If you'd like to support my work and keep the ideas flowing, consider buying me a coffee! Your support means the world to me!

From C to Rust to Go: What Native Really Offers Today

Matt Miller — Thu, 17 Apr 2025 08:50:00 +0000

Introduction

In the age of frameworks and abstraction, native programming languages might feel like a thing of the past. But truth is—languages like C, Rust, and Go are still powering the core of everything: operating systems, browsers, servers, devices, and now even some parts of the web.

So, when should you reach for native languages instead of JavaScript frameworks, Python backends, or Flutter UIs?

Let’s explore the raw power, use cases, and reasons to go native, even in 2025.

1️⃣ What Do We Mean by “Native Languages”?

In this context, we're talking about compiled, low-level, system-access-capable languages, like:

C / C++ – Classic, close-to-the-metal
Rust – Memory-safe, modern alternative to C
Go – Fast compile times, simplicity, built for concurrency
Zig, Assembly, Nim, etc. – also in the native league

These languages produce machine-level binaries, not interpreted scripts. They’re used where performance and control matter most.

2️⃣ Why Go Native? The Case for Full Control

🔥 Raw Speed

Native languages compile to machine code, resulting in:

✔ Faster execution

✔ Lower memory overhead

✔ Fine-grained performance tuning

Use case: Game engines, crypto tools, video processing, embedded firmware

🧠 System-Level Access

Want to:

Hook into system APIs?
Write a kernel module?
Access peripherals directly? Native is the way.

Use case: Device drivers, OS development, hardware controllers

🛡 Security & Memory Management

✅ Rust in particular is gaining popularity for offering both:

Memory safety (no segfaults, no garbage collector)
Blazing-fast performance

💡 Even Microsoft and Google are rewriting some components in Rust for security reasons.

🧰 Tiny Footprints

C and Go binaries can be tiny (<1MB)
No bloated runtimes or node_modules folders

Perfect for:

Embedded devices
IoT hardware
CLI tools and system daemons

3️⃣ Where Native Still Dominates

Domain	Why Native Wins	Popular Languages
Operating Systems	Full system control, drivers	C, C++, Rust
Game Development	Real-time graphics, physics engines	C++, Rust
Embedded Systems	Tight memory, hardware interaction	C, Rust, Go
Blockchain / Crypto	Security, performance, portability	Rust, Go, C++
Browsers / Compilers	Complex, high-performance internals	C++, Rust

📌 Even modern tools like Chrome, Firefox, Docker, and Kubernetes are written (at least partly) in native languages.

4️⃣ But Native Has Its Downsides…

Let’s be honest—it’s not all roses.

❌ Slower Development

Boilerplate code
Verbose syntax
Longer setup & learning curve

❌ Memory Management Pain (C/C++)

Manual allocation/deallocation
Potential for segmentation faults, leaks, buffer overflows

❌ Less Accessible to Beginners

Steeper learning curve
Less forgiving of mistakes
Not always beginner-friendly tooling

💡 Tools like Rust and Go aim to fix this—but they still require more upfront discipline than modern frameworks.

5️⃣ Where Native Is Making a Comeback

Modern developers are blending native languages with higher-level stacks:

Rust + React → Native-powered backend with a slick frontend
Go + REST/gRPC → Super-performant microservices
Tauri (Rust) + Svelte/React → Electron alternative with tiny binaries
WASM (WebAssembly) → Run native modules in the browser!

📌 You can write your “core logic” in a native language and expose it via a web or mobile UI.

💡 Final Thoughts: Native Is Still Relevant—And Powerful

✔ Native isn’t dead. It’s just matured.

✔ It’s not always the fastest to build—but it’s often the fastest to run.

✔ If performance, control, or safety matters, go native.

✔ And thanks to WASM, Tauri, and modern toolchains—you don’t have to choose one or the other.

💬 Your Thoughts?

Are you using a native language in your stack? Or are you curious but hesitant to dive in? Let’s talk about it in the comments!

Enjoying the content? If you'd like to support my work and keep the ideas flowing, consider buying me a coffee! Your support means the world to me!

When Web Meets Hardware: USB, Serial, and the New Web Frontier

Matt Miller — Wed, 16 Apr 2025 13:15:00 +0000

Introduction

For years, browsers were walled gardens—great for viewing, interacting, and typing into forms, but completely isolated from your system hardware.

But now, modern browser APIs like WebUSB and Web Serial are breaking those walls down.

The result? The web can talk to physical devices, flash firmware, debug microcontrollers, and even run remote repair services—no desktop app needed.

Let’s explore how this tech is changing what's possible with web apps—and what it means for tools like NeedROM, Arduino, and more.

1️⃣ WebUSB: The Browser Gets Its Hands Dirty

What It Does:

WebUSB gives JavaScript in your browser the ability to talk to USB devices directly.

✅ Read and write to devices

✅ Flash firmware

✅ Send commands, update configs

✅ Fully user-permissioned

🧠 Use Cases:

GrapheneOS Web Installer A full OS installer for Android phones, right from the browser—no command line, no external tools
3D printer firmware utilities
Device management dashboards
Custom USB tools for embedded engineers

🔗 WebUSB on MDN

💡 This turns any website into a platform-specific configuration utility. Imagine flashing a router or dev board—without leaving Chrome.

2️⃣ Web Serial: Serial Ports, No Terminal Needed

What It Does:

Web Serial lets a web app open a serial connection (e.g., COM ports, UART, USB-to-Serial converters) and read/write just like PuTTY or Minicom.

✅ Log data from microcontrollers

✅ Send CLI-style commands to connected devices

✅ Create serial monitors in the browser

✅ Replaces native terminal tools in many workflows

🧪 Use Cases:

Arduino and ESP-based devices
Debugging 3D printers or IoT hardware
Bootloader communication
Teaching embedded programming—in-browser!

🔗 Web Serial on MDN

💡 The web becomes a live console, perfect for labs, education, and dev tooling.

3️⃣ The End of "Download This Tool First"

Think about sites like:

🔧 NeedROM.com – Offers custom Android firmware

🧩 Router/modem forums – Share flash tools and updates

🖨 3D printer communities – Offer slicers, firmware, config utilities

The current flow:

Download a ZIP
Install custom drivers
Run some Windows-only .exe
Hope it works on your machine

🛠 The Future Flow (with WebUSB):

Open a web page
Plug in your device
Grant browser permission
Flash, configure, done. No drivers. No installs.

💥 With these APIs, the browser becomes a universal installer, debugger, and controller.

4️⃣ Developer Experience: The Stack Behind the Magic

✅ WebUSB / Web Serial APIs — Supported in Chrome, Edge, and Chromium-based browsers

✅ JavaScript or TypeScript frontend

✅ Optionally paired with WebAssembly for fast parsing/processing

✅ Can use Service Workers to support offline functionality

💡 Bonus: Pair With WebRTC

Combine Web Serial with remote support via video + data sharing
Offer "live unbricking" help in real time via web tools

5️⃣ Limitations & Security Considerations

🧱 Limitations:

Not supported in Firefox/Safari (yet)
Requires HTTPS (secure origin)
Device compatibility must be implemented per vendor

🛡 Security:

All access requires explicit user permission
Can only interact with allowed devices
Great sandboxing compared to native tools

💡 Still, this is serious access—devs should treat it with the same care as native apps.

💡 Final Thoughts: Browsers as the New OS for Hardware Tools

✔ The web is no longer limited to forms and files

✔ With WebUSB and Web Serial, it’s now a platform for:

→ Device repair

→ Firmware flashing

→ Debugging

→ Hardware education

→ Secure remote support

"Download this tool" may soon become "Open this URL."

💬 Your Thoughts?

Have you used any browser-based hardware tools? What would you love to see built with this tech? Let’s chat in the comments!

Enjoying the content? If you'd like to support my work and keep the ideas flowing, consider buying me a coffee! Your support means the world to me!

Distribution & Dev Workflow: Shipping Software vs Deploying the Web

Matt Miller — Tue, 15 Apr 2025 13:15:00 +0000

Introduction

Building an app is only half the battle—the other half is getting it into users’ hands.

Traditional software requires packaging, distribution, and updates. Web apps? You just hit “deploy”, and it’s live for everyone. Sounds like a dream, right?

Let’s dive into how software shipping compares to web deployment, and why each has its own set of challenges, benefits, and hidden stress points.

1️⃣ Shipping Native Software: A Developer’s Checkpoint Hell

Before a user ever launches a native app, you have to:

Build binaries for multiple OSes (Windows, macOS, Linux)
Package dependencies and installers
Sign code with trusted certificates
Test across environments
Publish to app stores or release platforms
Handle manual updates, patches, and version rollbacks

🧱 Pros:

✔ Works offline

✔ Greater control over system-level resources

✔ No dependency on a browser

❌ Cons:

❌ Slower iteration cycles

❌ High friction updates (especially if users disable auto-update)

❌ Difficult to hotfix once shipped

❌ OS-specific bugs and compatibility issues

💡 Native apps feel “finished” when shipped—which also means more risk if something breaks.

2️⃣ Deploying Web Apps: CI/CD Heaven (or Chaos)

Web development shifted everything left. Now, pushing an update is as simple as:

git commit -m "fix: spacing bug"  
git push

…and if you have CI/CD set up:

🎉 It’s live.

🔄 Web Deployment Workflow (Typical):

Code pushed to main
CI pipeline runs tests, builds assets
Auto-deploy to staging/production
Changes reflect instantly (or within minutes)

🟢 Pros:

✔ Ship features quickly

✔ Fix bugs without user intervention

✔ A/B test and roll back in real-time

✔ Platform-agnostic—one deployment for all users

🔴 Cons:

❌ Instant = risky if untested

❌ Breaking changes affect everyone, all at once

❌ Requires strong CI/CD discipline

❌ Browser cache issues can delay updates

💡 Summary: Web deploys are fast—but demand confidence, automation, and rollback plans.

3️⃣ Update Philosophy: Versioning vs Streaming

🖥️ Native Apps

Traditional versioning (v1.0.1, v1.1, etc.)
Users manually download or auto-update
Backward compatibility is crucial
Apps may live on for years without being updated

🌍 Web Apps

Continuous delivery—often no visible version
Small updates shipped daily or weekly
Users always on the latest build
Easy to A/B test different UI flows or feature toggles

📌 Dev takeaway:

Web is great for iteration
Software needs to be rock solid before shipping

4️⃣ Shipping Tools: Software vs Web DevOps Stack

Task	Native Stack	Web Stack
Building	Make/CMake, MSBuild, Xcode	Webpack, Vite, esbuild
Testing	XCTest, Google Test, NUnit	Vitest, Jest, Cypress, Playwright
Packaging	NSIS, Inno Setup, Electron Builder	Vercel, Netlify, Docker (for APIs)
Deployment	App Stores, GitHub Releases	CI/CD: GitHub Actions, GitLab, Vercel
Rollbacks	Manual (revert & release again)	Instant (revert commit or redeploy)

💡 Native apps often require heavier infrastructure and more platform-specific tooling. Web thrives on automation and cloud-first tooling.

5️⃣ Team Workflow Differences

Native Teams:

QA, Dev, Release, Ops often separated
Feature cycles take weeks to months
Releases are rare and coordinated

Web Teams:

More agile and iterative
Developers often own the full delivery pipeline
Releases happen daily or even multiple times per day

💡 In web, "move fast and fix things" is the norm. In software, it’s "measure twice, ship once."

💡 Final Thoughts: Pick Your Pipeline Wisely

✔ Web makes shipping faster, but demands tighter feedback loops and CI/CD discipline

✔ Native software gives you more control, but slows down iteration

✔ In both cases, delivery is a key part of product success—not just an afterthought

💬 Your Thoughts?

What’s your preferred workflow: versioned, packaged software—or fast, continuous deployment? Let’s chat in the comments!

Enjoying the content? If you'd like to support my work and keep the ideas flowing, consider buying me a coffee! Your support means the world to me!