flash: an AEN801 slot0 flash needs four values nothing in the chain emits -- no ATOC signing step, an ELF artefact, no probe selection

[alpCaner]

Summary

tan flash cannot complete a slot0 MRAM flash on E1M-AEN801 without four
values nothing in the chain supplies. Found by running Target 1 (tan-cli#268's
last precondition) on the real board — e1m-aen-evk-01, E8 AE822, J-Link
SN 603000869, DPS-150 Vin 16.0 V — end to end through tan.

Every refusal below is correct behaviour. The defect is that the pipeline
never produces what the refusals ask for, so "scaffold → build → flash entirely
through tan" is not achievable on this SoM today.

Measured, in order

tan init --from-example peripheral-io/blink → exit 0, 9 files.
tan build → exit 0, m55_he ok + m55_hp ok, slot0-linked (8001xxxx).
Then:

1. No signed ATOC, and nothing signs one.

flash.entry-failed alif_mram_jlink: flash_args.atoc (the signed ATOC blob) and
flash_args.atoc_address are both required. Both flows burn the SAME signed ATOC
-- sign it with the SETOOLS `app-gen-toc` step and pass the ...

What the SDK actually emitted for the slice:

flash_method: zephyr_west_flash
flash_args:
  jlink_flash_device: AE822FA0E5597LS0_M55_HE

No atoc, no atoc_address, and no step anywhere runs app-gen-toc. I had
to run SETOOLS by hand (app-gen-toc -f <app>-slot0.json → ATOC at
0x8057ea50) and inject both fields into build/system-manifest.yaml.

SETOOLS is license-gated and not redistributable, which is exactly why this
needs a decision rather than a quick patch — see "The decision" below.

2. output_artefact is zephyr.elf, but a slot0 loadbin needs the raw .bin.

flash.entry-failed alif_mram_jlink: flash_args.slot0_load_address is set but the
artefact .../zephyr.elf is not a raw .bin -- refusing to loadbin it at
slot0_load_address, which would write the artefact's own headers into MRAM

This is tan-cli#311's guard firing on real silicon, and it was right — that
write would have put ELF headers into on-die MRAM. But the sibling
zephyr.bin is sitting right next to the .elf in the same build dir, so tan
refuses over something it could resolve.

3. No probe selection → the flash cannot connect on a multi-probe host.

flash.entry-failed alif_mram_jlink[m55_he]: J-Link>si SWD | J-Link connection
not established yet but required for command. | Connecting to J-Link ...FAILED:
Cannot connect to the probe/programmer.

The generated script has no -SelectEmuBySN. It only worked after I set
flash_args.jlink_serial: 603000869 by hand. This bench has three J-Links,
and — per flashing-and-bench-debugging-aen — the AEN probe's serial
603000869 is cloned by the GD32 bridge probe on a different board, so an
unpinned connect can attach to hardware the reservation does not cover. The
error text also names none of this.

4. slot0_load_address is never emitted, so the mramxip two-blob shape
never arms even though both cores link 8001xxxx.

After injecting all four: tan flash --core m55_he → exit 0, and slot0
byte-matched the flashed .bin on all four words
(20004250 80015A51 8001F9F3 80015A3D) and survived a true cold power-cycle
at 16.0 V. So the burn path itself is sound — only its inputs are missing.

The decision this needs

Signing is the load-bearing one, and it is a product call, not a patch:

• (a) tan runs app-gen-toc when SETOOLS_DIR resolves. Makes
  tan flash self-sufficient on a licensed host; makes tan depend on a
  license-gated vendor tool and forces a policy for hosts without it.
• (b) alp-sdk signs during build and emits atoc/atoc_address into
  system-manifest.yaml. Keeps tan vendor-neutral and keeps SETOOLS on the
  build side where the toolchain already lives; means tan flash alone can
  never produce a flashable AEN image from an unsigned tree.
• (c) Neither — document it. Say plainly that AEN801 MRAM flashing requires
  a manual SETOOLS step, and have tan flash print that recipe instead of a
  bare field-missing refusal.

I lean (b): securing-the-alp-sdk-position keeps the portable <alp/*>
surface vendor-clean, and a license-gated binary is a build-time concern. But it
makes tan flash structurally unable to stand alone here, which is worth
saying out loud.

What I am fixing now, tan-side, regardless of that decision

Neither depends on the signing answer:

• Resolve the raw .bin sibling when a slot0 loadbin needs one and the
  artefact is an ELF, instead of refusing. flash: plan_alif_mram_jlink loadbin's the slot0 app with no is_raw_bin guard; an ELF artefact would write headers into MRAM #311's guard stays exactly as
  strict for anything that is genuinely not a raw image — it should refuse a
  .hex, and refuse when no sibling .bin exists.
• Name probe selection in the connect failure. Cannot connect to the probe/programmer should say that no flash_args.jlink_serial was pinned,
  and that on a host with several probes the connect is ambiguous.

Not in scope here

slot0_load_address (4) is a build-time property — it is only correct when the
app was built CONFIG_USE_DT_CODE_PARTITION=y, which tan cannot detect. That
belongs with whoever emits the manifest, same as the signing answer.

Blocks

tan-cli#268 — Target 1 ("entirely through tan") cannot pass on E1M-AEN801 until
the signing question is answered.

Verified on feat/v06-batch @ 063c4b1, tan 0.5.0-rc4.

[alpCaner]

Decision (maintainer): the customer supplies SETOOLS, tan drives it, tan warns when it is missing

Resolving the open question from the issue body. Not option (b) or (c) — a
blend that keeps tan usable without redistributing anything license-gated:

• The customer downloads SETOOLS themselves (from Alif; it is license-gated
  and alp-sdk does not and will not redistribute it) and points tan at its
  path — SETOOLS_DIR, or an explicit path on the flash args.
• tan runs app-gen-toc itself when that path resolves, so tan flash
  completes end to end for a customer who has done the one unavoidable
  download. No hand-signing, no hand-editing system-manifest.yaml, no pasting
  an address that changes every build.
• When it does NOT resolve, tan warns and says exactly what to do —
  where to get SETOOLS and how to point tan at it — instead of today's bare
  flash_args.atoc (the signed ATOC blob) and flash_args.atoc_address are both required, which tells a customer a field is missing without telling them
  that field is produced by a vendor tool they have never heard of.

atoc_address is derived from app-package-map.txt, never asked for: it is a
build-time output of the signing step that shifts on every rebuild, and the
bench runbook says outright not to hardcode it.

Why this shape

It keeps the license boundary where it belongs — tan ships no vendor binary and
resolves nothing implicitly — while removing the four manual steps that made
"scaffold → build → flash entirely through tan" impossible on this SoM. The
customer does the one thing only they can do (accept Alif's licence and
download), and tan does the rest.

Tracking as the remaining half of this issue; the two tan-side items
(sibling .bin resolution, probe-selection diagnostic) already landed in #352
as a4ef232.

[alpCaner]

Fixed on dev in ac79d4c (PR #352), and verified by running that freeze in a pristine ubuntu:24.04 carrying only ca-certificates, git, python3 -- not by code presence.

dev IS this repo default branch, so Closes does fire here; this issue was filed after the PR body closing-keyword list was written, so it was never in it. Closed by hand -- a merged PR body cannot close retroactively.

tan flash --help carries --setools-dir and names SETOOLS, so the license-gated tool is discoverable without failing first. Signing runs through a customer-supplied path with precedence flag > SETOOLS_DIR > manifest.

Item 4 of this issue (slot0_load_address still supplied by the customer) was out of scope by the issue own text and remains so.