Audit of the custom_meshtastic_* manifest on the variants backing the
newest boards, against the protobuf HardwareModel enum, the compiled
HW_VENDOR, the board flash size and the artwork actually published by
the web flasher. No support flag changes here - actively_supported is
left exactly as each variant already had it.
ThinkNode M9 had no HW_VENDOR arm, so every M9 has been reporting
PRIVATE_HW while its manifest advertised 131; add the mapping and
rename the slug to the enum name (THINKNODE_M9) it is meant to mirror.
Seeed SenseCAP Mesh-Tracker X1 moves from the PR matrix to release, and
its images entry now points at seeed_mesh_tracker_x1.svg, which is what
the flasher actually ships - the hyphenated name resolved to nothing.
T-Beam BPF, T-Beam 1W and Heltec Wireless Tracker V2 declared the
architecture as "esp32s3"; the value is copied verbatim into the
manifest, and the flash flow matches on the normalized "esp32-s3".
T-Beam BPF and M5Stack Unit C6L both build default_16MB.csv on 16 MB
flash but declared no partition scheme, which leaves the flasher on the
4 MB fallback offsets for a legacy clean install.
Meshnology W10 and W12 gain the artwork and vendor tag that already
exist for them.
The M9's variant.h defines ST7789_CS, so TFTDisplay.cpp compiles its
ST7789 LGFX branch, which reads SPI_FREQUENCY for the panel write clock
(SPI_READ_FREQUENCY, its pair, is already in variant.h). The flag was only
set in the -tft env, so `build (thinknode_m9, esp32s3)` has failed on
develop since the board landed in #10908:
src/graphics/TFTDisplay.cpp:504:30: error: 'SPI_FREQUENCY' was not
declared in this scope; did you mean 'SD_SPI_FREQUENCY'?
Move the flag up into thinknode_m9_base, keeping the 75 MHz the -tft env
already used for the same panel and matching the SD card's 75 MHz on the
bus they share. The -tft env inherits the base flags, so device-ui's
LGFX_GENERIC.h - which falls back to 20 MHz when the macro is absent -
still sees the identical value.
Ben Meadors