Point RAK OTA guides to compatible OTAFIX 2.4.10

docs/ota_easy.md

@@ -339,8 +339,8 @@ before installing either image.
 
 For a build that uses only the 2.54 mm headers, use the unified
 `RAK_4631_repeater_unified_lora_ota` or
-`RAK_3401_repeater_unified_lora_ota` image with its matching adaptive
-OTAFIX 2.4.8 bootloader. Wire `CLK` to J10 `TX1`, `DO` to J10 `RX1`, `DI` to
+`RAK_3401_repeater_unified_lora_ota` image with its matching compatible
+OTAFIX 2.4.10 bootloader. Wire `CLK` to J10 `TX1`, `DO` to J10 `RX1`, `DI` to
 J11 `IO1`, and `CS` to J11 `AIN1`; keep the `CS` pull-up and J12 power wiring.
 This gives up UART1 GPS/PPS but leaves I2C sensors and the RAK3401 radio
 available. See the [header-only wiring table](ota_nrf52_qspi.md#header-only-w25q16-wiring-for-the-unified-rak-images).

docs/ota_nrf52_bootloader_update.md

@@ -16,14 +16,19 @@ be replaced with the exact ABI-3 self-update-capable OTAFIX build over USB/BLE
 DFU or SWD. MeshTower SD also requires the BLM2 retained-auth version to be
 provisioned locally before either application or bootloader OTA.
 
-The adaptive RAK3401 and RAK4631 OTAFIX 2.4.8 profiles support application
-full and delta updates, but not bootloader self-update. Their running
-bootloader protects `0xF4000..0x100000` with the nRF52840 ACL before starting
+The released adaptive RAK3401 and RAK4631 OTAFIX 2.4.8/2.4.9 profiles support
+application full and delta updates, but not bootloader self-update over LoRa.
+USB UF2 and local Bluetooth/serial Legacy DFU bootloader updates still work.
+Their running bootloader protects `0xF4000..0x100000` with the nRF52840 ACL before starting
 MeshCore. This includes the MBR parameter page at `0xFE000`, so an application
 cannot initiate `COPY_BL` even after verifying a signed bootloader package.
 Hardware testing on a RAK3401 confirmed the MBR SVC enters a bus fault and
-leaves the installed bootloader unchanged. Migrate these profiles with their
-exact-board UF2 or local DFU package; do not offer a bootloader mOTA for them.
+leaves the installed bootloader unchanged. For new RAK installations use the
+normal [OTAFIX 2.4.10](https://github.com/mikecarper/Adafruit_nRF52_Bootloader_OTAFIX/releases/tag/v0.11.0-OTAFIX2.4.10)
+compatible `*_auto` bootloader. Existing standard `3401_DFU` / `4631_DFU`
+devices can receive its signed bootloader `.mota` over LoRa. Devices already
+running `3401_AUTO_DFU` / `4631_AUTO_DFU` need the matching 2.4.10 recovery
+bridge installed locally before switching to the normal image.
 
 ## Storage layouts
 

docs/ota_nrf52_qspi.md

@@ -145,7 +145,7 @@ bootloader pairs are not interchangeable.
 
 ### Header-only W25Q16 wiring for the unified RAK images
 
-The unified RAK repeater images and matching OTAFIX 2.4.8 adaptive bootloaders
+The unified RAK repeater images and matching OTAFIX 2.4.10 compatible bootloaders
 also support a W25Q16 through the RAK19007 2.54 mm headers. This arrangement
 does not need an IO-connector interposer or underside SPI solder points:
 

docs/ota_user_guide.md

@@ -106,7 +106,7 @@ flash consumes no WisBlock slot, so a supported GPS can remain in slot A.
 
 The unified RAK repeater images additionally support a header-only W25Q16
 layout, using J10 `TX1`/`RX1` and J11 `IO1`/`AIN1`. This layout needs the
-matching adaptive OTAFIX 2.4.8 bootloader and gives up UART1 GPS/PPS; I2C
+matching compatible OTAFIX 2.4.10 bootloader and gives up UART1 GPS/PPS; I2C
 sensors remain available. See the [pin table](ota_nrf52_qspi.md#header-only-w25q16-wiring-for-the-unified-rak-images).
 
 The ordinary full-sensor `RAK_4631_repeater` image remains too large for the

docs/releases/1.17.1.7.md

@@ -8,7 +8,7 @@ The release family contains 536 qualified firmware profiles on five GitHub relea
 
 - Match the exact board and radio variant. Use the application image only with a compatible bootloader and partition layout.
 - For an ESP32 that needs the expanded Full layout, flash the exact merged image over USB, or use a supported exact board and role migration ZIP from the utility release for a staged Wi-Fi or LoRa route. The 94 migration packages and complete bundle are included there. Read the package README before installation; the bridge writes the partition table and a power loss can require cable recovery. Run `get storage.layout` on the installed firmware if supported to see its live partitions; version alone cannot prove the installed layout. Do not send a loose app-only Full image directly to an older layout.
-- nRF52 application UF2 and DFU packages do not install a bootloader. Use the matching OTAFIX 2.4.8 bootloader where required.
+- nRF52 application UF2 and DFU packages do not install a bootloader. Use the matching [OTAFIX 2.4.10](https://github.com/mikecarper/Adafruit_nRF52_Bootloader_OTAFIX/releases/tag/v0.11.0-OTAFIX2.4.10) bootloader where required. Standard RAK `3401_DFU` / `4631_DFU` bootloaders can receive the matching signed bootloader `.mota` over LoRa with a compatible OTA application. Devices already running the older `*_AUTO_DFU` identity require a local recovery bridge before installing the normal 2.4.10 image.
 - The RAK 3x72, Tiny Relay, Wio-E5 Mini, and Wio-E5 USB Companion images retain their framed USB transport and 32 KiB LittleFS area. Packet diagnostics are omitted on these four 256 KiB STM32WL targets to keep the application within flash.
 
 ## Build verification