feat(m2-prep): image-bake skeleton (Option A hardware unblock) - #40
Closed
gHashTag wants to merge 2 commits into
Closed
feat(m2-prep): image-bake skeleton (Option A hardware unblock)#40gHashTag wants to merge 2 commits into
gHashTag wants to merge 2 commits into
Conversation
added 2 commits
July 4, 2026 16:08
Adds scripts/m2/bake-image.sh (8-stage skeleton) and scripts/m2/README.md (runbook + non-claims). Not executable from sandbox — DRY_RUN=1 by default; DRY_RUN=0 path deliberately unimplemented until an executor with a physical SD-reader fills in the FIT-layout / arch / device-path TODOs. Stages: 1. verify-input sanity-check image, MAC syntax, smoke payload, tools 2. dump-ramfs dumpimage extract (STUB, needs FIT layout) 3. unpack-ramfs gunzip + cpio -idm (STUB) 4. inject MAC to /etc/board-mac; smoke-m1 to /usr/local/bin 5. repack-ramfs cpio -o -H newc | gzip -9 6. mkimage wrap ramfs + kernel into new .ub 7. verify-output dumpimage -l diff + sha256 8. flash guarded, refuses DRY_RUN=0 without operator fill-in Purpose: turn M2 image-bake from a research problem into a runbook the moment an SD-reader is physically attached. Removes the 'reinvent the sequence each time' cost for boards 01/02/03. Blast-radius policy: flash board 01 first, verify boot, only then touch 02/03. Trinity rule preserved: no chip, no TRI. This does NOT claim M2 is done. phi^2 + phi^-2 = 3
…eate QSPI boot from scratch' Live board probe (2026-07-04) surfaced: the target board boots TRANSIENTLY over network (bootcmd: bootp; ... bootm), with kernel and ramfs landing in RAM from DHCP/TFTP. mtd3 (qspi-linux, 30MB, the persistent boot partition) reads all 0xff — empty. No SD-card event in dmesg either. There is no 'stock-image.ub' on the board to dump, inject, and repack. Consequence: bake-image.sh's 8-stage skeleton is correct for the 'modify existing image' pathway, but that pathway does not exist on this hardware without either: (1) Puzhi SDK / firmware source (kernel + dtb + rootfs template), or (2) a vendor-supplied bootable SD image + boot-mode pin change. Reverse-engineering kernel + dtb from live RAM is technically possible but licensing and reproducibility are unclear; not recommended. Recorded findings verbatim in README under 'Findings (2026-07-04)' and 'Unblock preconditions'. No code change to bake-image.sh — the skeleton is still correct for case (2). PR #40 remains draft. Non-claims: - W4 is not 'nearly done'. - The skeleton does not build QSPI boot images. - No further sandbox work on scripts/m2/ unblocks anything until SDK or vendor SD image arrives. Anchor: phi^2 + phi^-2 = 3
Owner
Author
|
Superseded by actual working SD boot recipe (docs/W12_SESSION_REPORT.md). 3/3 boards alive, M1 crypto PASS on ARM. |
gHashTag
pushed a commit
that referenced
this pull request
Jul 23, 2026
…in thing works Seven waves built the NAT stack as proven-but-unused modules. This wave makes the actual call use them, end to end. CallManager gains an additive, env-gated connection path autoConnectViaRendezvousIfConfigured(): gather (STUN) -> seal (CandidateOffer) -> publish/fetch (Rendezvous, addressed by SHA256(room)) -> open -> Ice.connect -> startCall() on the pair the connectivity check punched. It is OFF unless TRINET_RENDEZVOUS / TRINET_ROOM / TRINET_MEDIA_PORT are set, so the working same-subnet call is untouched (default no-op guard). Also: register Rendezvous.swift in desktop/project.yml (it was harness-only from wave #48; CallManager referencing it failed to compile until it was in the target). VERIFIED LIVE, reproduced, on a new rig — smoke/rendezvous_call.sh + a runnable relay smoke/rendezvous_serverd.swift built from the real Rendezvous.swift Mailbox: two TriNetMonitor processes, knowing ONLY a shared room name (no peer IP), found each other through the blind relay and established a forward-secret ENCRYPTED media session — audio decoded both ways (1705/1705, then 1445/1453 on the repro). Boundaries, stated honestly: - Loopback (one machine): proves discover + exchange + punch + encrypted media over real UDP, NOT traversal of a real NAT (that needs two separate NATs). - Two instances share the keychain identity + TOFU pins on one host, which the security layer reads as an identity change and refuses; the rig gives each a distinct TRINET_KC_ACCOUNT/TRINET_PINS_KEY (the #40 pattern). Not a call bug. - video recv=0 in this rig because the camera produced no NAL units (video sent=0 too) — an environment condition; video rides the identical transport.send path that carried the audio. - Cone-NAT scope: the transport reuses the punched local port; a symmetric NAT needs the punch socket handed to the transport (fd hand-off) — the next step. Mac-only. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
Skeleton for Option A (M2 milestone: TUN + ETX on 3 physical boards).
Turns image-bake from a research problem into a runbook the moment an
SD-card reader is physically attached to the executor machine (Mac / cloud).
What is in
inject MAC + smoke-m1 → repack → mkimage → verify → flash). `DRY_RUN=1`
by default; `DRY_RUN=0` path deliberately unimplemented.
Explicit non-claims
Path to `DRY_RUN=0`
Operator fills 4 TODOs on the executor machine (FIT layout, target arch,
init-hook location, SD device path). Blast-radius policy: flash board 01
first, verify boot, only then 02/03.
Draft — do not merge
Kept draft until an executor with a physical SD-reader confirms:
Once confirmed, this PR is updated with the filled-in stages and only
then considered for merge.
phi^2 + phi^-2 = 3