lpc8xx: convert 5 stub workflows to real builds (Stage 8 of #487) — orchestrator + upstream proof are in

[zackees]

TL;DR

fbuild build . -e <variant> works for all five ArduinoCore-LPC8xx variants in upstream CI today. The five .github/workflows/build-lpc*.yml files in this repo still carry the Stage-1 no-op stub headers from PR #476, and that note is now stale: PR #488 (Stage 2 orchestrator) merged 2026-06-07, and PR #521 (project-local variants/<variant>/pins_arduino.h resolver) merged shortly after — together they close the last hole that kept the per-board CI slot at "echo and pass."

Evidence — upstream green runs

zackees/ArduinoCore-LPC8xx installs fbuild from PyPI and runs fbuild build . -e <platform> against its own platformio.ini. Latest-main runs as of 2026-06-09, all ✅:

• fbuild / lpc845brk → https://github.com/zackees/ArduinoCore-LPC8xx/actions/runs/27182402201
• fbuild / lpcxpresso804 → https://github.com/zackees/ArduinoCore-LPC8xx/actions/runs/27182311515
• fbuild / lpcxpresso845max → https://github.com/zackees/ArduinoCore-LPC8xx/actions/runs/27182311504

Upstream _fbuild.yml body is bare:

```yaml

• run: pip install --upgrade fbuild
• run: fbuild --version
• run: fbuild build . -e ${{ inputs.platform }}
  ```

No shims, no patches. The orchestrator + project-local variants resolver do all the work.

Stub workflows to un-stub

Workflow	Variant	Origin
build-lpc804.yml	lpc804	PR #476 — Stage-1 stub
build-lpc845.yml	lpc845	PR #476 — Stage-1 stub
build-lpc845brk.yml	lpc845brk	Just added — stale stub copy on arrival
build-lpcxpresso804.yml	lpcxpresso804	Just added — stale stub copy on arrival
build-lpcxpresso845max.yml	lpcxpresso845max	Just added — stale stub copy on arrival

Each header still claims "Stage 2 not yet implemented"; the body just echoes. That header is wrong as of #488 — the three new files inherited the stale comment from the lpc804/lpc845 template.

Two options for the conversion

Option A — In-tree fixtures (parity with every other board)

1. Add `tests/platform//{platformio.ini,.ino,README.md}` for the three new variants.
2. Add `crates/fbuild-config/assets/boards/json/.json` modeled on `lpc845.json` (cpu, ram/rom from NXP data sheets, `extra_flags` reflecting the per-variant `CPU_LPC*` define).
3. Drop the per-workflow echo block; switch each to `uses: ./.github/workflows/template_build.yml` with `firmware-ext: bin`.

Pros: Consistent with every other board build; CI is hermetic.
Cons: Three more board JSONs and three more fixtures to maintain locally.

Option B — Upstream-integration workflow

One parameterized job that clones `zackees/ArduinoCore-LPC8xx` (pinned SHA), runs `fbuild build . -e ` for each variant.

Pros: Single source of truth for the variants list; no JSON/fixture drift here.
Cons: External-repo state can break our CI; harder to bisect locally; departs from the per-board pattern this repo standardized on.

Recommendation: Option A — `lpc804`/`lpc845` already have in-tree fixtures, so the delta is just three JSON files + three fixtures. Optionally keep an Option-B smoke job as belt-and-suspenders.

Related

• META: [META] LPC8xx end-to-end support: orchestrator + Arduino framework + real FastLED sketches #487 — this work is Stage 8 — unstub CI workflows in the umbrella
• PR feat(nxplpc): real Stage-2 build orchestrator (#477, part of #487) #488 — Stage-2 orchestrator (merged 2026-06-07)
• PR feat(nxplpc): pick up project-local variants/<variant>/pins_arduino.h #521 — project-local `variants//pins_arduino.h` resolver
• Upstream: `zackees/ArduinoCore-LPC8xx` (variant source of truth)

cc @zackees