summaryrefslogtreecommitdiff
path: root/cmd/sbc_harness/static
diff options
context:
space:
mode:
Diffstat (limited to 'cmd/sbc_harness/static')
-rw-r--r--cmd/sbc_harness/static/Documentation/harness_flash_bin.txt24
-rw-r--r--cmd/sbc_harness/static/Documentation/harness_uptime_txt.txt22
2 files changed, 33 insertions, 13 deletions
diff --git a/cmd/sbc_harness/static/Documentation/harness_flash_bin.txt b/cmd/sbc_harness/static/Documentation/harness_flash_bin.txt
index 115f2ee..1b58d6d 100644
--- a/cmd/sbc_harness/static/Documentation/harness_flash_bin.txt
+++ b/cmd/sbc_harness/static/Documentation/harness_flash_bin.txt
@@ -2,14 +2,20 @@ NAME
/harness/flash.bin
DESCRIPTION
- Access to the flash storage chip (where the harness firmware
- is stored).
+ Access the flash storage chip (where the harness firmware is
+ stored).
- Any number of readers may read the flash contents.
+ Reading from the file reads the raw flash contents.
- Only one writer can have the file open at a time; once the
+ Writing to the file does not accept raw data; instead the data
+ must be encapsulated in the [Intel Hex] format, with the Hex
+ file writing to the region 0x1000_0000-0x1010_0000. While less
+ convenient than verbatim data, the Hex format provides in-band
+ checksums and EOF-markers that help prevent rendering the
+ harness unbootable with corrupted or truncated writes. Any
+ holes in the Intel Hex file are filled with "1" bits. Once a
+ complete Intel Hex file has been written without error and the
file is closed, the harness reboots into the new firmware.
- Writes to the top half of the chip will fail.
BUGS
- The size of the chip is configured at compile-time. If the
@@ -21,13 +27,17 @@ BUGS
chip will crash.
- When writing to the flash using this file, only half of the
- chip capacity is usable; the top half and bottom half are
- mirrors of each-other. This is to avoid the firmware
+ chip capacity is usable (the size of the region specified
+ above is half the chip size); the top half and bottom half
+ are mirrors of each-other. This is to avoid the firmware
crashing as its program text is overwritten; the firmware is
executing out of the bottom half, and writing to the top
half; once the file is closed, a minimal in-RAM function
copies the top half to the bottom half and reboots.
+SEE ALSO:
+ [Intel Hex]: https://archive.org/details/IntelHEXStandard
+
AUTHOR
Copyright (C) 2025 Luke T. Shumaker <lukeshu@lukeshu.com>
SPDX-License-Identifier: AGPL-3.0-or-later
diff --git a/cmd/sbc_harness/static/Documentation/harness_uptime_txt.txt b/cmd/sbc_harness/static/Documentation/harness_uptime_txt.txt
index 1ab86f7..09e9243 100644
--- a/cmd/sbc_harness/static/Documentation/harness_uptime_txt.txt
+++ b/cmd/sbc_harness/static/Documentation/harness_uptime_txt.txt
@@ -3,14 +3,24 @@ NAME
DESCRIPTION
Reading this file gives a text string of the format
- `sprintf("%uns\n", uptime_ns)` indicating the harness's uptime
- in an integer number of nanoseconds.
+
+ {ns}ns
+ [[[[{y}y]{d}d ]{h}h]{m}m]{s.09}s
+
+ That is: the first line is simply the harness's uptime in an
+ integer number of nanoseconds; and the second line is this
+ same number in a more human-readable form; divided into
+ seconds, minutes, hours, days, and years.
BUGS
- Using nanoseconds gives the illusion of more precision than
- there actually is; the harness' clock only has microsecond
- resolution; the last 3 digits of the returned nanosecond count
- will always be 0.
+ - Using nanoseconds gives the illusion of more precision than
+ there actually is; the harness' clock only has microsecond
+ resolution; the last 3 digits of the returned nanosecond
+ count will always be 0.
+
+ - In the human-readable form, the days are always exactly
+ 60*60*24 seconds (leap seconds are ignored), and the years
+ are always exactly 365 days (leap years are ignored).
AUTHOR
Copyright (C) 2025 Luke T. Shumaker <lukeshu@lukeshu.com>