Commit graph

7 commits

Author SHA1 Message Date
c83b40fe5e feat(deploy): enable pcscd on upboard (sintra/tejo) for NFC gate
The access gate (ADR-003, #86) only wired services.pcscd + the pcsc
polkit rule into batm3.nix, so the tap-to-enter reader was invisible on
upboard machines. Port the same device-agnostic wiring to upboard.nix
(HID Global OMNIKEY 5022, 076b:5022) so the gate works on the sintra dev
unit — and on tejo — when #86 lands on dev and the nightly upgrade pulls
it.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018ivBosaWmv8vwFE7ejrdHW
2026-09-19 10:34:45 +02:00
7e90719508 refactor(deploy): share UP Board serial hardware between installed + live ISO
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>
2026-07-02 21:31:36 +02:00
7c1011d382 chore(nix): bump nixpkgs 24.05 → 24.11
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>
2026-06-01 19:12:11 +02:00
2551c6fcf8 fix(nixos/upboard): release ttyS4 from kernel console for F56 dispenser
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>
2026-06-01 19:08:03 +02:00
b7aa10e7fb fix(nixos/upboard): force-load eMMC stack in initrd + align /boot label
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>
2026-06-01 19:08:03 +02:00
Patrick Mulligan
143ae9ff0b feat(nix): add tejo hardware support and per-model auto-upgrade
- 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>
2026-03-06 08:54:50 -05:00
Patrick Mulligan
19d43c2939 feat(deploy): add NixOS live USB ISO for ATM hardware testing
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>
2026-02-18 20:11:23 -05:00