rpi-hwid 0.0.post5__tar.gz

rpi_hwid-0.0.post5/.github/workflows/ci.yml

@@ -0,0 +1,66 @@
+name: CI
+
+# The same gates as local development (ruff, mypy --strict, pytest with
+# coverage) on every push to main and every pull request. A green run is what
+# "mergeable" means -- and what "releasable" means: publish-pypi.yml is
+# triggered by this workflow COMPLETING on main and proceeds only when it
+# succeeded, so a red push to main is never published. Renaming this workflow
+# breaks that trigger.
+on:
+  push:
+    branches: [main]
+  pull_request:
+
+concurrency:
+  group: ci-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    timeout-minutes: 20
+    strategy:
+      fail-fast: false
+      matrix:
+        python-version: ["3.11", "3.12", "3.13"]
+    steps:
+      - uses: actions/checkout@v5
+        with:
+          fetch-depth: 0  # full history so hatch-vcs can derive the version
+
+      - name: Install poppler (pdftoppm, for the label QR check) and a monospace font
+        run: |
+          sudo apt-get update
+          sudo apt-get install -y --no-install-recommends poppler-utils fonts-dejavu-core
+
+      - uses: astral-sh/setup-uv@v7
+
+      - name: Install the matrix Python
+        run: uv python install ${{ matrix.python-version }}
+
+      - name: Sync all extras and the dev group
+        run: uv sync --all-extras --dev --python ${{ matrix.python-version }}
+
+      - name: Lint (ruff)
+        run: uv run ruff check
+
+      - name: Type-check (mypy --strict)
+        run: uv run mypy
+
+      - name: Tests + coverage gate
+        run: uv run pytest
+
+  # The two probe files must stay runnable by the oldest python3 a Pi in the
+  # field carries (Raspbian stretch: 3.5). Byte-compile them with a real 3.5
+  # from the python:3.5 image (uv has no 3.7 build for this runner, and 3.7
+  # would not have been the right grammar anyway); the test suite separately
+  # refuses f-strings, which 3.5 lacks.
+  probe-old-python:
+    runs-on: ubuntu-latest
+    timeout-minutes: 10
+    steps:
+      - uses: actions/checkout@v5
+      - name: Byte-compile the probes with python 3.5
+        run: >-
+          docker run --rm -v "$PWD:/src" -w /src python:3.5-slim
+          python -W error -m py_compile src/rpi_hwid/probe.py src/rpi_hwid/fpga.py

rpi_hwid-0.0.post5/.github/workflows/publish-pypi.yml

@@ -0,0 +1,69 @@
+name: Publish to PyPI
+
+# Every GREEN push to main is a release. The version is derived from git by
+# hatch-vcs (see pyproject.toml): vX.Y at a tag, vX.Y.postN N commits later, so
+# each commit produces a new, unique version -- no manual bump.
+#
+# This workflow is gated on CI: it runs when the "CI" workflow (ruff, mypy,
+# pytest + coverage, the old-python probe check) COMPLETES for a push to main,
+# and the build job only proceeds when that run SUCCEEDED, so a red push to
+# main is never published. The workflow_dispatch path stays for manual re-runs.
+#
+# Publishing uses PyPI Trusted Publishing (OIDC): there is no API token in the
+# repo; the `pypi` environment + trusted publisher are registered (see
+# RELEASING.md).
+on:
+  workflow_run:
+    workflows: [CI]
+    types: [completed]
+    branches: [main]
+  workflow_dispatch:
+
+jobs:
+  build:
+    # workflow_run fires on EVERY completion (failure and cancelled included);
+    # only a successful CI run is a release. Dependent jobs inherit the skip.
+    if: >-
+      github.event_name == 'workflow_dispatch' ||
+      github.event.workflow_run.conclusion == 'success'
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v5
+        with:
+          # A workflow_run checkout defaults to the default branch HEAD, which
+          # may already be PAST the commit CI just validated. Pin to the SHA
+          # CI actually ran on, so the published version is exactly the one
+          # that went green.
+          ref: ${{ github.event.workflow_run.head_sha || github.sha }}
+          fetch-depth: 0  # full history + tags for hatch-vcs version derivation
+
+      - uses: astral-sh/setup-uv@v7
+
+      - name: Build sdist + wheel
+        run: uv build
+
+      - name: Show derived version
+        run: ls -1 dist/
+
+      - uses: actions/upload-artifact@v7
+        with:
+          name: dist
+          path: dist/
+
+  publish:
+    needs: build
+    runs-on: ubuntu-latest
+    # Trusted Publishing requires an OIDC token and a named environment.
+    environment: pypi
+    permissions:
+      id-token: write
+    steps:
+      - uses: actions/download-artifact@v8
+        with:
+          name: dist
+          path: dist/
+
+      - name: Publish to PyPI (OIDC trusted publishing)
+        uses: pypa/gh-action-pypi-publish@release/v1
+        with:
+          skip-existing: true

rpi_hwid-0.0.post5/.gitignore

@@ -0,0 +1,63 @@
+# Python
+__pycache__/
+*.py[cod]
+*.egg-info/
+.eggs/
+build/
+dist/
+.venv/
+venv/
+
+# Tooling caches
+.pytest_cache/
+.ruff_cache/
+.mypy_cache/
+.cache/
+.uvcache/
+
+# Coverage artifacts (pytest-cov / coverage.py)
+.coverage
+.coverage.*
+htmlcov/
+
+# hatch-vcs writes this at build/editable-install time; it is derived from git.
+/src/rpi_hwid/_version.py
+
+# Sphinx build output (docs/Makefile's BUILDDIR). Read the Docs builds from a
+# clean checkout; a local `make -C docs html` writes here.
+/docs/_build/
+
+# Debian build byproducts (dpkg-buildpackage writes to the parent dir; local
+# builds may drop these in-tree).
+/built-debs/
+*.deb
+*.buildinfo
+*.changes
+/debian/.debhelper/
+/debian/files
+/debian/python3-netgear-switch-library/
+/debian/debhelper-build-stamp
+
+# Project-local scratch
+tmp/
+
+# Claude Code local config and subagent-driven-development scratch
+/.claude/
+/.superpowers/
+
+# Overlay-mount character-device dotfiles present in this repo's working tree —
+# never track these.
+/.bash_profile
+/.bashrc
+/.gitconfig
+/.gitmodules
+/.idea
+/.mcp.json
+/.profile
+/.ripgreprc
+/.vscode
+/.zprofile
+/.zshrc
+
+# Playwright MCP scratch output
+.playwright-mcp/

rpi_hwid-0.0.post5/LICENSE

@@ -0,0 +1,202 @@
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

rpi_hwid-0.0.post5/PKG-INFO

@@ -0,0 +1,122 @@
+Metadata-Version: 2.5
+Name: rpi-hwid
+Version: 0.0.post5
+Summary: Raspberry Pi hardware identity: what a Pi wears, what powers it, which FPGA board it hosts, and print-ready labels for all of it.
+Project-URL: Homepage, https://github.com/mithro/rpi-hwid
+Project-URL: Issues, https://github.com/mithro/rpi-hwid/issues
+Author-email: Tim Ansell <me@mith.ro>
+License-Expression: Apache-2.0
+License-File: LICENSE
+Keywords: fpga,hat,inventory,labels,poe,raspberry-pi
+Classifier: Operating System :: POSIX :: Linux
+Classifier: Programming Language :: Python :: 3
+Classifier: Topic :: System :: Hardware
+Requires-Python: >=3.11
+Provides-Extra: check
+Requires-Dist: pillow>=10; extra == 'check'
+Requires-Dist: zxing-cpp>=2; extra == 'check'
+Provides-Extra: labels
+Requires-Dist: pillow>=10; extra == 'labels'
+Requires-Dist: reportlab>=4; extra == 'labels'
+Requires-Dist: segno>=1.6; extra == 'labels'
+Requires-Dist: svglib>=1.5; extra == 'labels'
+Description-Content-Type: text/markdown
+
+# rpi-hwid — Raspberry Pi hardware identity
+
+What is this Raspberry Pi wearing, what powers it, and what is soldered to
+it? `rpi-hwid` answers from the Pi itself, from evidence the firmware and
+kernel already expose but nothing collects: HAT ID EEPROMs (including the
+ones the firmware never reads), the Pi 5's own verdict on its USB-C supply,
+the PMIC's input and RTC-cell voltages, the fan header, the USB tree, and
+which network interfaces are soldered down. A separate module does the same
+for an FPGA board attached to the Pi. A collector runs it over ssh across a
+fleet, and a label generator turns the collected data into sticker labels
+that carry only what cannot change.
+
+```
+pip install rpi-hwid            # or: uv tool install rpi-hwid[labels]
+
+rpi-hwid probe                  # on a Pi
+rpi-hwid probe --json --fpga --jtag
+rpi-hwid collect --out data/ -J jump.example.org rpi5-netv2 pi@10.21.1.10
+rpi-hwid labels --data data/ --out labels.pdf
+rpi-hwid name --netv2 0x00742c4e63b9085c
+rpi-hwid revision c04170
+```
+
+The probe is one dependency-free file that runs on any Pi with python3 3.5
+or later, so it can also be sent over ssh with nothing installed there:
+
+```
+ssh pi@host 'python3 -' --json < src/rpi_hwid/probe.py
+```
+
+It needs passwordless `sudo` for `i2c-tools` and `vcgencmd`.
+
+## What the probe reads, and what each signal proves
+
+| signal | tells |
+|---|---|
+| HAT ID EEPROM at `0x50` | what the firmware read: `/proc/device-tree/hat` (official PoE HATs, Digilent Pmod HAT Adaptor, Google VoiceBonnet…) |
+| HAT ID EEPROM at `0x51`–`0x57`, read off the ID bus | boards the firmware **never reads**: Waveshare's PoE M.2 HAT+ (B) puts a well-formed HAT+ EEPROM at `0x52` (product string, pid `0x6d87`, a DT atom naming `pciex1`) |
+| devices on I2C bus 1 | Waveshare PoE HAT (B): SSD1306 at `0x3c` and PCF8574 at `0x20` |
+| USB tree | Waveshare PoE-ETH-USB-HUB-HAT on a Zero: a Terminus `1a40:0101` hub on the root port with an RTL8152 on its port 4 |
+| Pi 5 `max_current` | the firmware's USB-C verdict: 5000 after a PD contract, **3000 both for a 3 A resistor source and for no USB-C source at all** (a HAT on the GPIO 5 V pins), 1500 or 900 for a resistor source advertising that much — so 900/1500 proves an external USB-C supply |
+| Pi 5 PMIC ADC | 5 V input (GPIO-fed HATs 5.1–5.4 V, splitters 4.8–5.0 V) and the RTC cell (about 3 V fitted, under 0.01 V not) |
+| Pi 5 `cooling_fan` node | a fan on the Pi's own header |
+| interface drivers | soldered-down (SoC Ethernet, SDIO radio, the 3B+'s LAN7800) versus removable USB adapters, which are listed with their descriptors |
+| throttle flags | under-voltage now or since boot: all a 3B+, Zero or Pi 4 can say about its supply |
+
+The verdict names the power source where the evidence allows (`gpio-poe-hat`,
+`bonnet-poe`, `usbc-supply`, `usbc-pd-supply`) and says `ambiguous` or
+`undetermined` where it does not: an EEPROM-less GPIO PoE HAT on a Pi 5 and
+a 3 A USB-C splitter read identically, as do an EEPROM-less, I2C-less HAT on
+a 3B+ and any splitter. The switch-side 802.3af class narrows those (the
+bonnet is class 3, the M.2 HAT+ (B) class 4, an af-only HAT is never class 4)
+but that is read from the switch, not the Pi.
+
+## FPGA boards (`rpi_hwid.fpga`)
+
+Kept apart from the Pi probe because few people have one. From what the Pi
+sees without touching the FPGA: a NeTV2 running LitePCIe is PCIe `10ee:7024`
+with one 1 MiB BAR; an SQRL Acorn CLE-215+ is `1e24:021f` (or `10ee:7011`
+under other gateware) with 128 KiB + 64 KiB BARs — BAR sizes come from sysfs
+and a BAR is never mapped, because that wedges a host; a Digilent Arty is its
+own FT2232 with a `210319…` serial. With `--jtag`, openFPGALoader reads the
+idcode and Device DNA over the Arty's FT2232 or the host's GPIO harness
+(libgpiod, pins 27:22:4:17). With `--flash`, an Arty's SPI flash is
+identified by JEDEC id, which reloads the FPGA with openFPGALoader's bridge;
+note the S25FL128S and S25FL127S both answer `0x012018`.
+
+## Names
+
+`rpi-hwid name` derives short, distinct names from the immutable identifier:
+a NeTV2 from its Device DNA (`netv2-grove`), an Arty from its Digilent serial
+(`arty-hawk`). Both hash first, because the raw identifiers come in
+near-identical clusters. Arty names are a hash *chain* against a registry
+(pass `--names registry.json`), so adding a board never renames an old one.
+
+## Labels
+
+`rpi-hwid labels` lays out 63.5 × 38.1 mm labels, 21 to an A4 sheet (the
+Avery L7160 grid), from a directory of collected documents: one per Pi
+(model, memory and revision from the revision code, serial up the edge, HAT
+band, a QR per soldered-down MAC), one per FPGA board (name, die, DNA or
+serial with a QR, flash where read), one per removable USB network adapter
+(descriptors, MAC with a QR). Print at 100 %. `--outline` draws the die-cut
+edges for an alignment print on plain paper.
+
+The package ships only artwork it may: the public-domain USB trident. A
+`--artwork DIR` may add `raspberry-pi.svg`, `alphamax.png`, `digilent.png`
+and `netv2.svg`, which are trademarks of their owners (the Raspberry Pi
+logo is on the English Wikipedia file page; the Alphamax and Digilent marks
+are their GitHub organisation avatars); without them a label uses the
+maker's name in type.
+
+## Origin
+
+Worked out on a fleet of Pi Zero W, 3B+, 4 and 5 hosts carrying NeTV2, Acorn
+and Arty boards, powered by a mix of Waveshare PoE HATs and external PoE
+splitters, in September 2026. The rules above are what those boards showed;
+a board that behaves differently is a bug report.

rpi_hwid-0.0.post5/README.md

@@ -0,0 +1,98 @@
+# rpi-hwid — Raspberry Pi hardware identity
+
+What is this Raspberry Pi wearing, what powers it, and what is soldered to
+it? `rpi-hwid` answers from the Pi itself, from evidence the firmware and
+kernel already expose but nothing collects: HAT ID EEPROMs (including the
+ones the firmware never reads), the Pi 5's own verdict on its USB-C supply,
+the PMIC's input and RTC-cell voltages, the fan header, the USB tree, and
+which network interfaces are soldered down. A separate module does the same
+for an FPGA board attached to the Pi. A collector runs it over ssh across a
+fleet, and a label generator turns the collected data into sticker labels
+that carry only what cannot change.
+
+```
+pip install rpi-hwid            # or: uv tool install rpi-hwid[labels]
+
+rpi-hwid probe                  # on a Pi
+rpi-hwid probe --json --fpga --jtag
+rpi-hwid collect --out data/ -J jump.example.org rpi5-netv2 pi@10.21.1.10
+rpi-hwid labels --data data/ --out labels.pdf
+rpi-hwid name --netv2 0x00742c4e63b9085c
+rpi-hwid revision c04170
+```
+
+The probe is one dependency-free file that runs on any Pi with python3 3.5
+or later, so it can also be sent over ssh with nothing installed there:
+
+```
+ssh pi@host 'python3 -' --json < src/rpi_hwid/probe.py
+```
+
+It needs passwordless `sudo` for `i2c-tools` and `vcgencmd`.
+
+## What the probe reads, and what each signal proves
+
+| signal | tells |
+|---|---|
+| HAT ID EEPROM at `0x50` | what the firmware read: `/proc/device-tree/hat` (official PoE HATs, Digilent Pmod HAT Adaptor, Google VoiceBonnet…) |
+| HAT ID EEPROM at `0x51`–`0x57`, read off the ID bus | boards the firmware **never reads**: Waveshare's PoE M.2 HAT+ (B) puts a well-formed HAT+ EEPROM at `0x52` (product string, pid `0x6d87`, a DT atom naming `pciex1`) |
+| devices on I2C bus 1 | Waveshare PoE HAT (B): SSD1306 at `0x3c` and PCF8574 at `0x20` |
+| USB tree | Waveshare PoE-ETH-USB-HUB-HAT on a Zero: a Terminus `1a40:0101` hub on the root port with an RTL8152 on its port 4 |
+| Pi 5 `max_current` | the firmware's USB-C verdict: 5000 after a PD contract, **3000 both for a 3 A resistor source and for no USB-C source at all** (a HAT on the GPIO 5 V pins), 1500 or 900 for a resistor source advertising that much — so 900/1500 proves an external USB-C supply |
+| Pi 5 PMIC ADC | 5 V input (GPIO-fed HATs 5.1–5.4 V, splitters 4.8–5.0 V) and the RTC cell (about 3 V fitted, under 0.01 V not) |
+| Pi 5 `cooling_fan` node | a fan on the Pi's own header |
+| interface drivers | soldered-down (SoC Ethernet, SDIO radio, the 3B+'s LAN7800) versus removable USB adapters, which are listed with their descriptors |
+| throttle flags | under-voltage now or since boot: all a 3B+, Zero or Pi 4 can say about its supply |
+
+The verdict names the power source where the evidence allows (`gpio-poe-hat`,
+`bonnet-poe`, `usbc-supply`, `usbc-pd-supply`) and says `ambiguous` or
+`undetermined` where it does not: an EEPROM-less GPIO PoE HAT on a Pi 5 and
+a 3 A USB-C splitter read identically, as do an EEPROM-less, I2C-less HAT on
+a 3B+ and any splitter. The switch-side 802.3af class narrows those (the
+bonnet is class 3, the M.2 HAT+ (B) class 4, an af-only HAT is never class 4)
+but that is read from the switch, not the Pi.
+
+## FPGA boards (`rpi_hwid.fpga`)
+
+Kept apart from the Pi probe because few people have one. From what the Pi
+sees without touching the FPGA: a NeTV2 running LitePCIe is PCIe `10ee:7024`
+with one 1 MiB BAR; an SQRL Acorn CLE-215+ is `1e24:021f` (or `10ee:7011`
+under other gateware) with 128 KiB + 64 KiB BARs — BAR sizes come from sysfs
+and a BAR is never mapped, because that wedges a host; a Digilent Arty is its
+own FT2232 with a `210319…` serial. With `--jtag`, openFPGALoader reads the
+idcode and Device DNA over the Arty's FT2232 or the host's GPIO harness
+(libgpiod, pins 27:22:4:17). With `--flash`, an Arty's SPI flash is
+identified by JEDEC id, which reloads the FPGA with openFPGALoader's bridge;
+note the S25FL128S and S25FL127S both answer `0x012018`.
+
+## Names
+
+`rpi-hwid name` derives short, distinct names from the immutable identifier:
+a NeTV2 from its Device DNA (`netv2-grove`), an Arty from its Digilent serial
+(`arty-hawk`). Both hash first, because the raw identifiers come in
+near-identical clusters. Arty names are a hash *chain* against a registry
+(pass `--names registry.json`), so adding a board never renames an old one.
+
+## Labels
+
+`rpi-hwid labels` lays out 63.5 × 38.1 mm labels, 21 to an A4 sheet (the
+Avery L7160 grid), from a directory of collected documents: one per Pi
+(model, memory and revision from the revision code, serial up the edge, HAT
+band, a QR per soldered-down MAC), one per FPGA board (name, die, DNA or
+serial with a QR, flash where read), one per removable USB network adapter
+(descriptors, MAC with a QR). Print at 100 %. `--outline` draws the die-cut
+edges for an alignment print on plain paper.
+
+The package ships only artwork it may: the public-domain USB trident. A
+`--artwork DIR` may add `raspberry-pi.svg`, `alphamax.png`, `digilent.png`
+and `netv2.svg`, which are trademarks of their owners (the Raspberry Pi
+logo is on the English Wikipedia file page; the Alphamax and Digilent marks
+are their GitHub organisation avatars); without them a label uses the
+maker's name in type.
+
+## Origin
+
+Worked out on a fleet of Pi Zero W, 3B+, 4 and 5 hosts carrying NeTV2, Acorn
+and Arty boards, powered by a mix of Waveshare PoE HATs and external PoE
+splitters, in September 2026. The rules above are what those boards showed;
+a board that behaves differently is a bug report.

rpi_hwid-0.0.post5/RELEASING.md

@@ -0,0 +1,42 @@
+# Releasing
+
+This project is a **rolling release**. There are no manual version bumps: the
+version is derived from `git describe` by `hatch-vcs` — `X.Y` at a `vX.Y`
+tag, `X.Y.postN` N commits after it — and **every green push to `main`
+publishes a new package** automatically:
+
+- `.github/workflows/ci.yml` — runs the gates (ruff, mypy --strict, pytest with
+  coverage) on every push and PR. A green run is what "mergeable" means, and it
+  is what triggers the release workflow.
+- `.github/workflows/publish-pypi.yml` — builds and uploads the wheel + sdist to
+  PyPI when CI **succeeds** on `main` (`workflow_run`; a failed or cancelled CI
+  run publishes nothing, and the checkout is pinned to the SHA CI validated).
+
+Merges to `main` use `--no-ff` merge commits so history stays linear per PR.
+
+## Tags
+
+Tags are the only human input to the version. `v0.0` sits on the root commit
+(so `git describe` works from the start of history, per the repo-setup
+guidance). To cut a new series, push an annotated `vX.Y` tag on `main` (a
+GitHub tag ruleset only admits `vXX.ZZZ`-shaped tags) — the next green CI run
+publishes `X.Y`, and every commit after it `X.Y.postN`. Never move or delete a
+tag that has been published from.
+
+## One-time human setup
+
+Done ONCE by a maintainer. **No secret or key is ever committed to the repo.**
+Until this is done, the publish workflow runs but its upload step fails safely.
+
+1. Create the project `rpi-hwid` on https://pypi.org, or let the first
+   trusted-publisher upload create it via a *pending publisher*.
+2. On PyPI, add a **Trusted Publisher** to the project with:
+   - Owner: `mithro`
+   - Repository: `rpi-hwid`
+   - Workflow filename: `publish-pypi.yml`
+   - Environment name: `pypi`
+3. In the GitHub repo, the **Environment** named `pypi` exists (created at
+   repo setup). No secrets needed — OIDC handles auth.
+
+After this, the next green push to `main` uploads to PyPI. `skip-existing:
+true` makes re-runs idempotent.