16 posts tagged stm32mp1, 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.
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.
An hour spent trying to open a window that was never going to be drawn, then the realisation that a Scenic graph is just data. Walking it and rendering to SVG found two layout bugs in a minute that had survived 49 tests and a review.
Counting down by subtracting the tick interval drifts on an embedded board. Deriving the remaining time from a monotonic deadline instead makes it drift-free by construction — and injecting the clock turns a 25-minute test into a map update. It also caught a real race.
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,…