Move to ESP-IDF v6.1-rc1; the P4's WiFi firmware finally boots

.github/workflows/release.yml

@@ -129,7 +129,7 @@ jobs:
             ~/.espressif
             ~/esp/esp-idf
           # Bump the suffix when changing the IDF version to invalidate.
-          key: esp-idf-v6.1-beta1-${{ runner.os }}-v1
+          key: esp-idf-v6.1-rc1-${{ runner.os }}-v1
 
       # The release-channel tag burned into the binary as MM_RELEASE (shown by
       # SystemModule alongside the semver). Same resolution as the release
@@ -172,24 +172,22 @@ jobs:
       - name: Build firmware
         uses: espressif/esp-idf-ci-action@v1
         with:
-          # Match the local development IDF (v6.1-beta1, commit b1d13e9f).
+          # Match the local development IDF (v6.1-rc1, commit 44f0c59f).
           # The project uses v6-era APIs — `esp_eth_phy_new_generic`, the new
           # mDNS component manager, `int clock_gpio` in the EMAC config (v5.x
           # had a strongly-typed enum). v5.4 fails to compile platform_esp32.cpp.
-          # `v6.1-beta1` is the espressif/idf Docker tag pinned to the same
-          # tagged beta the local pin uses — a fixed, signed pre-release (not the
+          # `v6.1-rc1` is the espressif/idf Docker tag pinned to the same
+          # tagged pre-release the local pin uses — fixed and signed (not the
           # rolling `release-v6.1` branch tag), so CI and local build the exact
           # same tree. This tracks the v6.1 line toward GA; re-pin to the `v6.1`
           # tag once it ships (a deliberate re-test pass, see docs/building.md).
-          esp_idf_version: v6.1-beta1
+          esp_idf_version: v6.1-rc1
           # The IDF target follows the firmware-key prefix: esp32s31* → esp32s31
           # (checked BEFORE esp32s3 — esp32s31 also startsWith 'esp32s3'),
           # esp32s3* → esp32s3, esp32p4* → esp32p4 (the only target that pulls
           # the ip101 PHY + esp_hosted, both manifest-gated on target == esp32p4),
           # everything
-          # else → esp32. (The matrix is the `ships` subset of firmwares.json;
-          # esp32p4-eth-wifi has ships=False in build_esp32.py so it stays out —
-          # its C6-slave Kconfig defaults don't survive a plain CI build.)
+          # else → esp32. (The matrix is the `ships` subset of firmwares.json.)
           target: ${{ startsWith(matrix.firmware, 'esp32s31') && 'esp32s31' || startsWith(matrix.firmware, 'esp32s3') && 'esp32s3' || startsWith(matrix.firmware, 'esp32p4') && 'esp32p4' || 'esp32' }}
           path: 'esp32'
           # We run our own builder (not the action's default `idf.py build`)

docs/architecture.md

@@ -257,7 +257,7 @@ Three distinct things, kept distinct in the vocabulary:
 - **deviceModel** — the whole assembled product, identified by its catalog name (`Olimex ESP32-Gateway Rev G`). This is *which hardware this is*. It is distinct from **`deviceName`**, *which individual unit this is* (per-unit identity the user sets — see [§ Device name](#device-name-one-identity-every-network-name-derives-from-it)); a **device** (the umbrella term) has a `deviceName` and a `deviceModel`.
 - **board** — the bare PCB *only*. The word survives in its literal sense: **on-board** LED, **on-board** peripherals, board-soldered pins — things physically *on the PCB*. (A deviceModel is a board plus whatever is wired onto it.)
 
-**Firmware** is the compiled binary: chip target plus which radios/peripherals/sdkconfig fragments are included. Today's variants: `esp32` (classic, WiFi **and** RMII Ethernet in one binary — Ethernet comes up only when a PHY is present, pins/PHY per deviceModel), `esp32-eth` (classic, Ethernet only, WiFi excluded), `esp32-16mb` (classic with 16 MB flash, WiFi + Ethernet), `esp32s3-n16r8` / `esp32s3-n8r8` (S3 with WiFi + W5500 SPI Ethernet), `esp32p4-eth` (Waveshare ESP32-P4-NANO, Ethernet only), `esp32p4-eth-wifi` (the same P4 hardware with WiFi via its on-board ESP32-C6 over esp_hosted). Each chip's firmware carries the Ethernet *driver(s)* it can host (RMII EMAC for classic/P4, W5500 SPI for S3); which PHY/pins a deviceModel uses is runtime config. Selected by `build_esp32.py --firmware <key>`, reported by `SystemModule.firmware`, used as the contract target key in scenarios.
+**Firmware** is the compiled binary: chip target plus which radios/peripherals/sdkconfig fragments are included. Today's variants: `esp32` (classic, WiFi **and** RMII Ethernet in one binary — Ethernet comes up only when a PHY is present, pins/PHY per deviceModel), `esp32-eth` (classic, Ethernet only, WiFi excluded), `esp32-16mb` (classic with 16 MB flash, WiFi + Ethernet), `esp32s3-n16r8` / `esp32s3-n8r8` (S3 with WiFi + W5500 SPI Ethernet), `esp32p4rev1-eth` (Waveshare ESP32-P4-NANO, Ethernet only), `esp32p4rev1-eth-wifi` (the same P4 hardware with WiFi via its on-board ESP32-C6 over esp_hosted), `esp32p4rev3-eth` / `esp32p4rev3-eth-wifi` (the same two images built for P4 **v3.x** silicon, which is not binary-compatible with rev <3.0 — untested, no v3 board on the bench). Each chip's firmware carries the Ethernet *driver(s)* it can host (RMII EMAC for classic/P4, W5500 SPI for S3); which PHY/pins a deviceModel uses is runtime config. Selected by `build_esp32.py --firmware <key>`, reported by `SystemModule.firmware`, used as the contract target key in scenarios.
 
 **deviceModel** is the physical hardware: chip + PCB + on-board peripherals (PHY, USB-serial, PSRAM, antenna), identified by its product name. Examples: `Olimex ESP32-Gateway Rev G`, `LOLIN D32`, `Generic ESP32 Dev`. A unit cannot identify its own deviceModel (no readable PCB ID on classic ESP32), so MoonDeck deduces it from the firmware where unambiguous (`esp32-eth*` ⇒ Olimex) and otherwise lets the user pick. It is stored on the unit as SystemModule's `deviceModel` Text control (display-only in the UI; HTTP `/api/control` writes still apply). MoonDeck mirrors the picked / deduced value to the unit via `POST /api/control` after each discover and after every dropdown change. The catalog of valid deviceModels lives at [web-installer/deviceModels.json](../web-installer/deviceModels.json), shared between MoonDeck and the web installer: MoonDeck reads it for its dropdown and HTTP push (plain REST on the LAN); the web installer reads it for its picker and pushes the whole entry — deviceModel plus every module/control — over serial during provisioning as REST ops (**"Improv = REST over serial"**, the `APPLY_OP` vendor RPC; see [ImprovProvisioningModule.md](moonmodules/core/moxygen/ImprovProvisioningModule.md)). Pushing over serial sidesteps the mixed-content block that stops an HTTPS installer page from POSTing to an `http://` device; an already-running device is re-configured via MoonDeck on the LAN.