etwenandClaude Opus 5
f5694345fb
The macro does warm and cold now, so "Reboot" was too narrow:
5_Blanton_Script_Reboot_Cycle.ttl -> 5_Blanton_Script_Boot_Cycle.ttl.
EN_Cold_Warm_boot in config.ttl picks which:
0 neither - for the A/B/C flow, where this macro is not used
1 reboot (warm), what the macro always did
2 cold, by writing the CB FPGA:
pcimem .../0000:05:00.0/resource0 0x480 w 0xD0000
Three things about that worth knowing before anyone runs it. Setting 0 and
then running this macro hangs it: nothing reboots, and the
wait "Booting in blind mode" underneath has no timeout, so it waits for a
boot that will never come. 0x480 is ICB_CTRL_REG in
docs/Blantons_FPGA_Registers.md and that table has no bit definitions for
it, nor is 0xD0000 written down anywhere in this repo. And the BDF
0000:05:00.0 is hard-coded, while blanton_fpga_pcimem.sh auto-detects the
CB FPGA precisely because it moves per unit - on a DUT where it is not at
05:00.0 this is a raw 32-bit write to an unknown register on some other
device. The cold path has not been run on hardware.
Separately, both stress logs are now removed before each run:
rm -rf /host/hw-eval/jobs/qfx5252-stress-{ssd,usb}.log
qfx5252-stress-* appends to its --log file and the macro cats the whole
thing afterwards, so every cycle printed back everything the cycles
before it had written. On the 199-cycle log from 2026-09-04 that was 289
lines at cycle 1 and 36,555 at cycle 199; at ~6.2 ms a line, which is
what a 115200 baud console costs, it accounts for +212 s of the +214 s
the cycle grew over the run. The stress itself is fixed at --runtime 30,
and the other eleven gaps between check points drifted by under 1.5 s
each. The DUT was never getting slower - the test was reading its own
history aloud, once per cycle.
Script A's header goes to V1.2.2 and its Version History covers all of
the above.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014RetWKFZFG1ZHcitQAyhwM