The sintra live ISO (live.nix) had no serial support — ftdi_sio and the
ttyJ5/ttyJ7 udev symlinks were only in hardware/upboard.nix (installed), so
booting iso-sintra on real hardware failed on the validator + F56 dispenser
while the disk image worked. The two definitions had already drifted (live's
tejo block lacked ttyS4).
Extract the UP Board serial peripherals (usbserial/ftdi_sio/cp210x, the
ttyJ4/ttyJ5/ttyJ7 udev symlinks + permissions, console=tty0) into
hardware/upboard-serial.nix and import it from both upboard.nix (installed
tejo + sintra) and live.nix (sintra only). Single source of truth — the two
artifacts can't drift again. Named upboard-serial (not sintra-serial) since
upboard.nix serves both tejo-installed and sintra-installed.
Camera + LED/SPI rules stay inline in upboard.nix (installed-specific; the
pairing camera works via getUserMedia without the scanner symlink). Verified
by eval: live sintra now carries ftdi_sio + console=tty0 + ttyJ7; installed
sintra/tejo unchanged (serial present, camera present, no console dupe).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Three breakages handled:
- hardware.opengl → hardware.graphics (renamed in 24.11). Touches
upboard.nix, douro.nix, batm3.nix, live.nix.
- vaapiIntel dropped — legacy pre-Broadwell driver, removed in
nixpkgs. UP Board (Cherry Trail) and OptiPlex 9030 (Haswell) both
use intel-media-driver, which stays.
- vaapiVdpau renamed → libva-vdpau-driver.
system.stateVersion stays 24.05 — convention is to never bump after
install. Existing Sintra and fresh flashes keep the 24.05 state
semantics; that's correct.
All 8 nixosConfigurations (4 models × {live,installed}) evaluate
clean with zero deprecation warnings on 24.11.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The Fujitsu F56 bill dispenser on Sintra is wired to the SoC's MMIO
UART at 0xa171b000, which the kernel enumerates as ttyS4 (the only
real on-board UART besides the legacy ttyS0 at I/O 0x3f8). The
existing kernelParams routed the kernel console through ttyS4, so
userspace could never open it: HAL crashed at startup with
"Input/output error setting custom baud rate of 9600" when trying
to initialise the dispenser, which in turn aborted the entire ATM
init chain in production mode (HAL failure → initError set → kiosk
shows "ATM unavailable" → Lightning client never gets to even try
talking to LNbits).
Two coordinated changes:
1. Drop `console=ttyS4,115200n8` from kernelParams. Keep `console=tty0`
so kernel messages still land on the framebuffer console during
boot. Anyone who wants a serial debug console can point it at
ttyS0 (the legacy 8250 at I/O 0x3f8) — that port stays free.
2. Extend the dispenser-tag udev rules: add `KERNEL=="ttyS4"
SYMLINK+="ttyJ7"` alongside the existing ttyS1 / ttyS5 entries.
Different UP Board variants enumerate the dispenser-side UART
under different kernel-allocated indices; whichever real device
shows up at boot gets the ttyJ7 alias HAL is wired to expect.
Diagnostic before/after on Sintra (`stty -F /dev/ttyJ7 9600`):
before: Input/output error
after: OK
Once this rolls out the renderer should progress past HAL init,
proceed to initializeLightningServices(), and start connecting to
LNbits over the nostr transport.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
First Sintra boot from the freshly-flashed eMMC panicked in stage 1:
An error occurred in stage 1 of the boot process, which must mount
the root filesystem on '/mnt-root' and then start stage 2.
mount: can't find /mnt-root/ in /proc/mounts
stage 2 init script (/mnt-root/nix/store/...nixos-system-bitspire/init) not found
Kernel panic - not syncing: Attempted to kill init!
Root cause: the UP Board's eMMC controller is enumerated via ACPI
(sdhci-acpi), but the initrd only had sdhci_pci available. /dev/mmcblk*
nodes never materialised in stage 1, so root-by-label resolution
silently failed and switch_root had nothing to chroot into. Tejo (same
hardware module) appears to have been getting lucky with a different
controller binding, or its eMMC firmware exposes PCI-style SDHCI.
- Add sdhci-acpi + mmc_block to initrd.availableKernelModules so the
block device infrastructure is present in the early-boot ramdisk.
- Force-load both via initrd.kernelModules so they're guaranteed to
fire before stage 1 init runs — leaving them on availableKernel
Modules alone relies on udev autoload firing in time, which it
wasn't.
Also a separate-but-adjacent fix in the same module: /boot was
declared as by-label/boot, but make-disk-image.nix with
partitionTableType="efi" labels the FAT partition "ESP". This was
the FIRST boot failure I hit (manually worked around with
`fatlabel /dev/mmcblk0p1 boot` while in the Alpine live image).
Aligning the declared label with what the image build produces means
future flashes don't need that hand-step. douro.nix already used ESP.
Build verified by `nix eval` on the sintra-installed config — initrd
kernelModules now contains [ "sdhci-acpi" "mmc_block" "dm_mod" ].
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Add tejo-specific udev rules for both UP Board and UP4000 variants
(serial symlinks ttyJ4/J5/J7, camera, LED SPI, I2C, USB autosuspend)
- Add USB serial kernel modules (usbserial, ftdi_sio, cp210x) for tejo
- Add tejo serial console kernel params (ttyS4 debug UART)
- Fix upboard.nix: hardware.graphics → hardware.opengl (NixOS 24.05)
- Add tejo-installed nixosConfiguration with model-specific auto-upgrade
- Parameterize auto-upgrade flake URL per machine model
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add NixOS configuration to build a bootable live USB ISO that runs the
ATM Electron app in kiosk mode on physical hardware (UpBoard). The ISO
boots from squashfs, auto-starts X11/openbox, and launches Electron in
production mode.
Key changes:
- deploy/nixos/live.nix: Live USB module (squashfs+tmpfs, no disk install)
- deploy/nixos/flake.nix: Nix flake with ISO build output
- deploy/nixos/provision-atm.sh: Auto-provision LP credentials via API
- deploy/nixos/build-iso.sh: End-to-end build workflow script
- apps/machine: Fix Electron production mode (ELECTRON_FORCE_PROD),
Vue Router hash mode for file:// protocol, relative asset paths
Build: cd deploy/nixos && bash build-iso.sh
Test: qemu-system-x86_64 -enable-kvm -m 2G -cdrom result/iso/*.iso
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
