hil_needs_revalidation Directory Reference

Directory dependency graph for hil_needs_revalidation:

Directories
	bkup_survival_demo
	compress_demo
	cpu1_pingpong_ipc
	epub_open
	epub_parse
	epub_toc
	ereader_shelf
	gpt_irq_demo
	lpm_deep_standby_1_demo
	lpm_deep_standby_2_demo
	lpm_deep_standby_3_demo
	lpm_idle_demo
	lpm_periodic_idle
	lpm_software_standby_demo
	lpm_ulpt_standby
	lpm_wake_matrix_demo
	lvd_monitor_demo
	mem_ecc_fault_demo
	mem_subsystem
	mpu_partition_simple
	pagecache
	pdg_delay_demo
	poeg_safe_shutoff
	power_profiler
	psa_crypto_hil
	ra8_cache_store_demo
	ra8_io_cache_demo
	ra8_io_demo
	ra8_io_fsfmt_demo
	ra8_io_sd_demo
	ra8_io_sdram_demo
	ra8_io_xspi_demo
	reflow_content
	reset_cause_demo
	rng_demo
	rot_verify_hil
	rsip_sha256_kat
	rtc_alarm
	rtc_periodic_demo
	touch_cal
	touch_demo
	tz_nsc_cgc_usb
	usb_selftest_wlun

Detailed Description

Apps that were in ../hw_validated/hil/ and failed a recorded full bench run. They sit here to preserve that negative evidence until a later run supersedes it. Each app's own README carries its suspected blocker.

Neither this directory nor hw_validated/hil/ is a live dashboard. Tier placement records the outcome that caused the last move; only a dated run of the current commit can support a current green/red claim.

A blocker written down is a hypothesis, not a verdict. One app here was labelled "needs an Ethernet peer"; it got one, and failed anyway – on a firmware regression that had been sitting on dev for a month behind that wrong label (#499). Expect clearing a blocker to sometimes reveal a defect rather than a pass.

They build like any other app and the target name does not change with the tier. Re-validating one is a git mv back into hw_validated/hil/; its hil.conf travels with it.

The recurring blockers

• The C6 sits on the Octo-SPI pins. The companion radio is wired onto the PMOD1 pins that are the Octo-SPI flash bus, so in that bench configuration storage-backed apps cannot reach their storage. A carrier PCB (#318) gives the C6 dedicated pins; until then, unwire it and re-run.
• Consumables and cabling. An unseated microSD fails a whole family of reader apps at once and reads as a code defect until someone looks at the board.
• The probe cannot see the outcome. Sleep and standby states the debugger cannot reach while the core is halted, and edges that need a scope or a current probe rather than a console line.
• A real regression. Triage against the last green run before assuming it is one of the above.

The coverage this tier gives up

For every app here, the recorded run that caused its move passed in tools/ra8_emulator and failed on the bench. Under the EIL == HIL rule, that historical divergence is worth keeping visible; it is not a current-pass claim.

But the EIL run set and the parity gate discover apps only under hw_validated/hil/, so moving an app here drops it from the enforcing EIL run set – no more per-hil.conf assertion in the emulator. The io-fabric demos are still booted by the emulator gates that resolve apps by name and are tier-agnostic, so their boot coverage survives; the assertion does not.