Recovery¶
This page tells you what to do when a slot does not boot, and what the factory recovery mode is. The eMMC layout and the boot sequence behind it are in Boot and storage.
The recovery ladder¶
Work down the ladder. Each step is more involved than the one before it.
- The previous slot. After a bad update, roll back: select the previous
slot with the panel's boot selector
(Updating) or with
ffboot(below). No flash path ever writes the slot that is running, and a written slot is verified before the boot selection moves to it, so the slot you came from is intact. - The factory recovery mode, below.
- An SD card. The bootloader can boot from an SD card that carries the
release disk image (
forgefirm-image-glowforge.rootfs.wic.gz). The boot selector andffbootlist the card as a target (Build for how the image is written). - The serial console. Log in at the console (Serial access). From the factory firmware, rerunning the installer recovers a broken ForgeFIRM install: it skips the archives it already has and rewrites the ForgeFIRM slot (Install).
ffboot¶
ffboot is the boot-slot tool. It is on the PATH in ForgeFIRM, and the
installer places it at /data/ffboot on the factory firmware:
ffboot -l # inventory: what is in each slot, what boots next
ffboot -e2 # select slot 2 for the next boot (-e1 for slot 1)
ffboot -l inventories every candidate (the eMMC slots, a legacy p4, and
an SD card) by a read-only mount: the version file of the system in it, and
the presence of a kernel, plus the current selection in the saved
environment. The output is machine-parsable; the control panel and the
installer reuse the same probe.
A target is probed first. ffboot refuses to select a slot that does not
look bootable (no kernel, or no recognizable rootfs); -f overrides. The
switch is atomic: one transaction sets all four environment variables
(mmcdev, mmchwpart, mmcpart, mmcroot). Rollback from a bad slot is
the same operation: select the previous slot. The eMMC has two 200 MiB rootfs
slots, mmcblk2p1 (slot 1) and mmcblk2p2 (slot 2); the saved U-Boot
environment selects the one that boots, and an SD card is a third boot
target.
The factory recovery mode¶
The factory recovery is a small system in the eMMC hardware boot partitions, separate from both rootfs slots. It is never updated in the field, so every machine runs its as-manufactured recovery. The ForgeFIRM installer never writes those partitions; it archives them (Installation). Two paths lead into recovery mode:
- The button at power-on. U-Boot polls the button at power-on for a recovery request.
- A blank or corrupt boot environment. The compiled-in default environment boots recovery, so a machine with no usable saved environment lands in recovery mode, not in a brick.
- A hardware watchdog timeout. U-Boot arms the SoC watchdog with a 60 s timeout before Linux starts. A kernel hard hang lets it reset the SoC, and the bootloader reads the timeout flag and boots recovery. Power-cycle the machine to boot normally again; the flag clears on a power-on reset. The serial console shows nothing from the hang through the recovery boot: the purple button is the sign. The recovery image takes the machine's network lease and answers ping, with no SSH; about two minutes pass from the hang to that point.
The recovery boots the factory's recovery kernel (3.14.28) and device tree
from the boot partitions, and runs the factory setup application: WiFi
setup and an access point, a log export, the firmware version, and a .fw
upload. An uploaded archive goes through the factory updater: fwup checks
its signature, writes it to slot A, and switches the boot environment to
that slot. The check uses the Glowforge keys, so the factory recovery
installs Glowforge firmware.
Planned: the recovery refresh¶
A refreshed recovery is planned. It replaces only the recovery userspace in
the boot partitions: the factory U-Boot, device tree, and recovery kernel
stay in place, and the tool never writes the bootloader region. From the
button hold, the refreshed recovery raises the access point and a web page
with the factory's user experience: upload a .fw verified against the
ForgeFIRM and the Glowforge keys (so a ForgeFIRM release and a factory
restore can both be installed from it), install from the archive on
/data, set the boot target, and export logs. The recovery ladder then
reads: previous slot, button-hold recovery, SD card, serial console.
Scope of the planned refresh
- Only the recovery squashfs in boot0 is replaced (the boot1
/usronly if needed). Nothing is written below offset 0xC0000 in boot0, so U-Boot is physically untouchable by the refresh tool. The factory DTB and the 3.14.28 kernel stay. - The userspace is a static busybox,
fwup, a small C web application (ulfius), andhostapd/wpa_supplicant. No Python. It must carry WiFi modules matched to kernel 3.14.28; whether they are lifted from the factory recovery or rebuilt from Glowforge's published GPL kernel source is an open decision. - The flash tool archives boot0 and boot1 first (the installer already
does), unlocks
force_ro, writes the high regions only, and verifies by readback. If both partitions are written, boot1 goes first and boot0 last.
The invariants and contracts behind this are in Install and update.