27 lines
1.2 KiB
Markdown
27 lines
1.2 KiB
Markdown
# Physical acceptance records
|
|
|
|
Start with [real-hardware setup](../../fds-os.wiki/Hardware-Setup.md) on the assembled Pi.
|
|
Then follow [the complete procedure](../../fds-os.wiki/Developer-Stress-Testing.md), including bay
|
|
calibration, repeatable device populations, explicit SAFE handling and separate
|
|
external timing measurements.
|
|
|
|
Copy `session-template.json` into a new results directory outside this source
|
|
folder. Replace nulls with observed values, retain raw captures and hashes, and
|
|
leave unperformed cases marked `not_run`. Record failures before attempting a
|
|
fix. Do not fill this record from VM results.
|
|
|
|
For example, on the build workstation:
|
|
|
|
```sh
|
|
mkdir -p out/hardware-session
|
|
cp tests/hardware/session-template.json out/hardware-session/session.json
|
|
```
|
|
|
|
On FDS, copy `tools/capture-hardware` to DATA and run it explicitly through Bash.
|
|
Use a fresh output directory each time; the usage guide explains volatile
|
|
captures when DATA itself is under test. Copy the resulting files into the
|
|
session directory after the test, preserving `status.tsv` and `SHA256SUMS`.
|
|
|
|
No file in this directory is evidence of a completed physical test until an
|
|
actual run is recorded. The template's null values mean unknown, never zero.
|