35 posts tagged embedded, newest first.
You cannot put a filesystem's hash inside that filesystem. Two U-Boot messages that were lies — “press any key to stop autoboot” when no key worked, and quotes vanishing from the kernel command line. Four attempts, three instructive failures, and a hardware SHA engine I did not know I was using.
The negative test that proves the chain is real: flip a single bit in a 52 MB root filesystem, get `data block 0 is corrupted`, and watch the board refuse. Why you cannot sabotage your own firmware the two obvious ways.
The hash of a filesystem cannot live inside it, so the kernel had to move somewhere signed. Then the two-command test: hand the bootloader rubbish and watch the kernel ignore it entirely. What that cost, and where the chain now ends.
You cannot sign a zImage. Why the signature goes on the FIT configuration rather than the kernel, the escape hatch that turns the whole thing into theatre, why the negative test needed two tampered images and not one, and the three ways the test lied to me.
TF-A verifying the next stage against a certificate chain inside the FIP — software, on blank fuses, refusing for real. Flipping one bit produced EAUTH on BL33 and a clean halt. Plus the honest limits of what that proves.
Signing is not encrypting — the thing burned into silicon is public and you could print it on a billboard. The chicken-and-egg the 32 bytes solve, the STM32 header field by field, four locks wearing one name, and the two things I got wrong and had to correct.
Secure boot on this chip comes down to 32 bytes in one-time-programmable memory, and a bit you can never un-blow. I started the project with a rule forbidding its own last step — and three of the four links in the chain turn out to enforce for real on completely blank silicon.
Authenticity, integrity, confidentiality and identity are four separate problems with four separate answers. Three private keys that must never be mixed up, why the firmware trust anchor does not identify a device, and the one I had backwards.
Scenes, graphs, components and drivers on an STM32MP157F-DK2 — then the four gotchas that compile cleanly and fail on the device: the required assets module, the child spec that is a plain list, the missing input: style that made every button inert, and text_align: :center not working.
An afternoon spent finding where a Nerves target's Erlang version is really decided — and discovering it is encoded in the filename of a patch inside a dependency I had never opened. Plus the Kconfig default that will silently move you to OTP 29 the moment you bump.
Between an Elixir process and a lit pixel on the DK2 there is an LTDC, a MIPI DSI host, an OTM8009A panel and a Goodix touch controller. I spent a day preparing to enable the Vivante GC NanoUltra, then read scenic_driver_local's source and found it renders in software to /dev/fb0.
The repeatable runbook, and the reason flashing a pre-made image left me with a 512 MB data partition instead of 28 gigabytes.
The board flashed perfectly and never reached Linux. A Kconfig choice split upstream had silently retargeted my bootloader at the wrong DRAM.
NXP's uuu dies at 8% on an Apple Silicon Mac. The board's own U-Boot has ums and fastboot, and those use bulk USB, which works fine.
Four packaging bugs between a Nerves system that builds and a firmware that flashes — plus the kconfig hang that looks exactly like a working build.
Why I wrote a custom Nerves base image file by file for a CompuLab IOT-DIN-IMX8PLUS instead of forking a sibling board's system.
Before I show you the first build attempt (and its failures), I need to clear up something that confused me at first.
On a desktop PC, when you plug in a USB device or install a PCI graphics card, the operating system discovers it automatically. PCI has enumeration.
I've been using Nerves for years, and for most of that time the boot process was a black box. Plug in power, wait a few seconds, get an IEx prompt. Magic.
I've been using Nerves for a while now. Raspberry Pi, BeagleBone — the usual suspects. You pull in the official system, write your Elixir code, burn firmware,…
The signed Nerves firmware boots. And a finding that deleted an open task: enabling CONFIG_IMX_HAB wires an automatic fail-closed authentication gate into booti itself, for every kernel boot, with no bootcmd changes at all. Plus a fleet gotcha about who can SSH in.
Wiring signing into the build, and a correction worth more than the wiring: I planned to point fwup.conf at signed artifacts, and that was the wrong layer entirely — the signed bootloader is not in the .fw file at all.
The same kernel-signing procedure as track A, on a different build — and it passed first time, because the two things that went wrong last time were checked rather than assumed. A 691,712-byte padding gap, and a signed range that goes through the IVT.
Three real bugs blocked the first three attempts: a nerves package version whose error message points nowhere near the cause, a missing .tool-versions, and the same SPL SRAM overflow track A hit. Plus the arm64 header field that is at offset 0x10, not 0x4.
The first series proved HAB secure boot on a disposable lab unit running stock Linux. This one carries it into a real Nerves system — in a fork, so the build that runs in the field is never at risk. Same board, different starting point, and several things that do not transfer.
Two fuse writes stand between a signed board and a locked one: the SRK hash, and the bit that makes the chip refuse unsigned code. Both are permanent. Here is exactly what they are, how to read their current state, and why I have not burned either.
Extending the chain from the bootloader to the kernel. The first signed Image failed with HAB_INV_ASSERTION — because I read NXP's own diagram literally and stopped the signed range one IVT short. How I decoded the event by hand and found the off-by-32-bytes.
Enabling CONFIG_IMX_HAB overflowed the SPL's SRAM budget by 10,440 bytes. Fixing that, computing the real CSF insertion offsets from the build's own binman node rather than NXP's generic one, signing with cst, and getting 'No HAB Events Found!' on hardware.
My imx-boot build failed LPDDR4 training and the gateway stopped booting before U-Boot. The cause was one Kconfig symbol. Recovering it took days, because uuu's SDP mode does not work on Apple Silicon and the board has two identical-looking micro-USB ports.
The first real build: a completely unsigned bootloader, on purpose, so that any problem is a build problem and not a signing problem. Two errors on the way, one of which is caused by a modern setuptools removing pkg_resources.
imx-boot is not one repository — it is U-Boot, ARM Trusted Firmware, NXP's imx-mkimage and the LPDDR4 training blobs, assembled together. Get one of them at the wrong version and it builds cleanly and fails to train memory. How I pinned all four using the board's own boot log.
Before touching a bootloader, take a backup you can actually restore from. On an i.MX8M Plus that means four separate things, two of which a dd of the main device silently misses — and one that is not block data at all.
Getting CST, generating the thirteen-key HAB PKI tree with hab4_pki_tree.sh, and building the SRK table and its fuse hash with srktool. Including the thing that script does silently if you do not read it first: it invents a passphrase for you, and the passphrase is 'test'.
Why i.MX8M secure boot needs thirteen key pairs rather than one, what 'open' and 'closed' actually mean, and which single 256-bit value ends up permanently burned into the chip. The concepts, before any tool touches anything.
What you need to follow this series: a CompuLab IOT-DIN-IMX8PLUS industrial gateway on an NXP i.MX8M Plus, a serial cable, and a spare unit you are willing to break. Plus the commands to confirm which variant you have, because it decides what you build.