fix(renode): a smoke whose CPU halts before executing anything still exits 0

[hkngln]

Summary

After #63 the Renode smoke really boots. It can still pass while executing nothing: the CPU halts on the first instruction fetch and tan renode exits 0.

Actual

tan --sdk-root /Users/hakan/.alp/sdk/v0.13.0 renode --core m55_hp --timeout 25 on a real E1M-AEN801 build:

16:23:18.8324 [INFO] System bus created.
16:23:19.6576 [INFO] sysbus: Loading block of 17984 bytes length at 0x20000140.
16:23:19.6666 [INFO] sysbus: Loading block of 120636 bytes length at 0x80000000.
16:23:19.6672 [INFO] sysbus: Loading block of 316 bytes length at 0x8001D73C.
16:23:19.6672 [INFO] sysbus: Loading block of 4 bytes length at 0x8001D878.
Starting emulation...
16:23:19.6935 [INFO] cpu: Guessing VectorTableOffset value to be 0x20000000.
16:23:19.7011 [ERROR] cpu: PC does not lay in memory or PC and SP are equal to zero. CPU was halted.
16:23:19.7025 [INFO] aen801: Machine started.
(aen801) 16:23:19.8066 [INFO] aen801: Machine paused.
16:23:19.8224 [INFO] aen801: Disposed.

Exit code: 0. Envelope ok: true.

Why it passes

Without --expect, commands::renode has exactly two failure signals: a non-zero natural_exit, and (as of #63) a latched argv rejection. A Renode that boots, halts the CPU, and shuts down cleanly trips neither — it exits 0 like a healthy run. So the smoke's default mode (no --expect) cannot distinguish "the firmware ran" from "the CPU never executed an instruction".

This is the same shape as the argv false-green #63 closed, one layer further in: there, Renode never started; here, it starts and does nothing.

Two separable questions

1. Which console lines should fail a smoke? A judgement call, and worth being conservative — too broad a rule turns healthy smokes red. Options, narrowest first:

• Fail only on the "never executed" markers: CPU was halted, PC does not lay in memory. Narrow, high-signal, matches this failure exactly.
• Fail on any Renode [ERROR] line. Broader; emulation ERRORs are not all fatal, so this risks false failures.
• Require --expect for a green smoke (no boot evidence, no pass). Strictest and the most honest, but it changes the default contract and every existing caller.

2. Why does the CPU halt on this image? Likely NOT a tan bug: Guessing VectorTableOffset value to be 0x20000000 right before the halt suggests the ELF's vector table is not where metadata/renode/alif_ensemble_e8.repl / .resc expect for this slice. The loaded blocks span both 0x20000140 (ITCM/SRAM) and 0x80000000 (MRAM), so the descriptor may need the MRAM-linked shape for m55_hp, or the .resc needs to set PC/VectorTableOffset explicitly. That belongs to the SDK's Renode descriptors, not the CLI — worth confirming before wiring any detection, since the detection should not paper over a descriptor bug.

Suggested split

• This repo: implement (1), starting with the narrow marker rule.
• alp-sdk: investigate (2) against metadata/renode/alif_ensemble_e8.{repl,resc} for an MRAM-linked M55 slice.

Environment

• tan built from feat/renode-core-select (feat(renode): --core <CORE_ID> to boot one slice of a multicore project #63, commit 05fde8a)
• Renode 1.16.1 (d66b0c2a-202606120852), macOS (Darwin 25.5.0)
• SoM: E1M-AEN801, slice m55_hp; SDK v0.13.0 at /Users/hakan/.alp/sdk
• Log: /Users/hakan/VSCodeProjects/alp-sample/build/renode.log

[alpCaner]

Fixed on dev by #72 (fc0cf30), which also landed #65's four open review findings.

Implemented option 1, the narrow marker rule: renode_cpu_halted matches only CPU was halted and PC does not lay in memory, latched per-line beside the existing argv-rejection latch and checked independently of --expect and natural_exit, emitting renode.cpu-halted. Not widened to any [ERROR] line, and the default contract is unchanged.

On your question 2 (why the CPU halts): #65's $vtor derivation is still inert until alp-sdk#947 updates the .resc, so this detection does not paper over the descriptor issue — it makes it fail loudly instead of passing.

One item stays open and is disclosed in the code rather than assumed away: the reset-vector check now added to elf_vector_table_base rests on e_entry == vector_table[1], which could not be re-confirmed against a real E1M-AEN801 zephyr.elf — no toolchain or non-native_sim ELF was available, and no bench data was invented. If it is ever wrong the function returns None and Renode falls back to its own guess, which this issue's own detection now reports. Worth a readelf -h / readelf -x .vectors on a real m55_he build before alp-sdk#947 lands.