Document where Moto/DFU entry is, and let a boot key hold PTT plus a key

The bootloader's DFU handler is reachable only when SRAM[0x20000020] is 3, which only a program that then resets can write. The application's 0x05DD takes that path only with ENABLE_OVERLAY; this build resets straight back into the application instead. Ruled out by measurement: PTT alone, PTT+SIDE1/SIDE2, MENU, a host byte in the boot window including 0x0530, and 0x05DD.

boot-key now reads a + separated list, because the firmware's own BOOT_GetMode() needs PTT and a matrix key together for every special boot mode. Tested against all four documented combinations.

README.zh-CN.md

@@ -339,6 +339,33 @@ v6.0.0 版把开机菜单和四个固件槽放在外部 flash 里：开机按住
   决定（默认 8 秒：开机路径可能花 20 秒把当前固件"采纳"进槽 0，之后才会去采样键盘）。
 - `tools/uvk5_slots.py` 做同样的事但离线：把槽写进 flash 镜像，并打印每个槽的内容。
 
+### MOTO/DFU 刷机，以及这份构建没有打开的开关
+
+出厂引导就在机器上，而且它**确实会说刷机协议**：真正的 `0x0518` / `0x0530` / `0x0519` 交互，
+38400 波特，在应用区之前的 10 KB 里。它不肯做的，是**从外部**进入那个模式。下面是量出来的，不是猜的：
+
+| 尝试进入 DFU 的方式 | 实际发生了什么 |
+| --- | --- |
+| 复位起按住 PTT | 普通启动。固件自己的 `BOOT_GetMode()` 在没有第二个键时返回 `BOOT_MODE_NORMAL` |
+| PTT+SIDE1、PTT+SIDE2、MENU | 进了应用的几个特殊模式（F_LOCK、AIRCOPY、MULTIBOOT），从不是引导 |
+| 开机窗口内主机发字节（含 `0x0530`） | 被忽略；PC 从未离开应用区 |
+| 固件自带的 `0x05DD`（reset）命令 | 普通复位，直接回到应用 |
+
+引导的判据只有一个字节：`ldrb r0,[r4]`，`r4 = 0x20000020`，与 1、2、3 比较，只有 **3** 才
+会进入 DFU 处理器。这个字节在 SRAM 里，所以它只能挺过**软**复位：必须是**正在运行的程序**写它
+然后复位。在固件里那就是 `overlay_FLASH_RebootToBootloader()`，而 `0x05DD` 只有在构建定义了
+`ENABLE_OVERLAY` 时才走那条路：
+
+    case 0x05DD: // reset
+        #if defined(ENABLE_OVERLAY)
+            overlay_FLASH_RebootToBootloader();
+        #else
+            NVIC_SystemReset();          <-- 这份构建走的是这里
+        #endif
+
+**所以 MOTO 刷机不是卡在模拟器上。** 引导能跑、DFU 处理器存在、进入条件已知且可复现；这份固件
+构建只是没有打开唯一能走到那里的那个开关。多系统版出于同样的原因有同样的性质——可以参考网页在
+没有开机菜单的构建上打印的那句提示。
 布局来自固件源码 `App/driver/mb_flash.h`：槽 0 在 `0x020000`，是内部镜像的备份；槽 1..4
 从 `0x040000` 起、每 128 KiB 一个；镜像从槽内偏移 4 KiB 开始；64 字节头部含魔数
 `FMB1`、镜像大小和 CRC-32。固件自带的 `0x0720`..`0x0727` 串口命令也按同样方式写槽，