Разбираюсь с очередной моделью Xiaomi, отличная система, неплохой по железу девайс, но как всегда не идеален. Попытки обновить китайскую версию на глобальную, или перепрошивка демо часов вводят часы в состояние, которую обычный пользователь может назвать труп.
Под капотом оказывается не совсем так, я покажу что происходит с прошивкой и почему выбранные архитектурные решения приводят к такому результату, а также покажу как исправить эту ситуацию.
Устройство системы
В данной модели довольно таки простая схема устройства: SoC Bestechnic BES2700iBP
с внутренним SPI Nand Flash на 8Mb, внешним SPI Nand на 512Mb с сенсорами, gnss и nfc.
Операционная система NuttX RTOS, c shell, на этот раз с движком JerryScript - модификация Xiaomi - AiotJS только в китайской версии, в глобальной просто вырезают. чтобы не заморачиваться с отсутствием глобальных приложений, без движка Lua - для него не хватило места во внутренней 8Mb флешке.
<“flash_bl”, 0, 0x7C0, 0>
<“flash_config”, 0x7C0, 0x40, 0>
<“flash_ap”, 0x800, 0x7800, 0>
Внутренний флеш размечен на следующие разделы, flash_ap - раздел основного приложения часов, flash_bl - bootloader, загрузчик системы, flash_config - конфигурация устройства.
Это типичное решение embedded систем и не только, загрузчик при старте проверяет режим разгрузки устройства, проверяет ошибки и решает куда дальше передать управление.
внешний флеш разбит на 2 раздела, разделы отформатированы в yaffs2
<“nand_system”, 0, 0x19000, 0>
<“nand_data”, 0x19000, 0x27000, 0>
Смертельное обновление
При попытке произвести обновление часов с китайской версии на глобальную происходит следующий казус
[ap] ****************App start!**************** [ap] **Software Version ap:[3.100.138] [ap] **Customer Version : M0TRAL_LTALM057_3.100.138_20260422_release_4978 [ap] **SecureBoot Status : [false] [ap] **Build at:Apr 22 2026-21:41:36 [ap] **By longcheer shanghai R&D [ap] ****************************************** [ap] **Partition[/system] Total Size:204160 KB Free Size:0 KB [ap] **Partition[/data] Total Size:318848 KB Free Size:296832 KB
Системная партиция забивается в 0ль файлами OTA пакета и OTA обновлятор падает.
Посмотрим что происходит в загрузчике
bootloader main_entry.c
int __fastcall bl_main(int a1, int a2, int a3) { boot_info_t data = {0}; uint32_t stack_chk = stack_check_val; uint32_t assemble_buf[5]; int ret; syslog(6, "bootloader start ...\n"); flash_init(); bootloader_start(0); /* --- Load boot info --- */ int boot_cause = get_boot_cause_veneer(); memset(&data, 0, sizeof(data)); ret = load_device_bootinfo(&data); syslog(6, "bootmode sw 0x%lx boot_cause:0x%lx read_ret:%d", bootmode_sw, boot_cause, ret); /* --- Abnormal reset handling --- */ if (data.start_mode == APP) { if (bootmode_sw & 0x8000000) { syslog(6, "abnormal_reset %d", ++data.abnormal_reset_counter); if (data.abnormal_reset_counter > 5) { data.start_mode = FACTORY; data.start_submode = 3; data.abnormal_reset_counter = 0; } save_device_bootinfo(&data); clear_sw_bootflag(0x8000000); } else if (data.abnormal_reset_counter) { syslog(6, "clean abnormal_reset %d", data.abnormal_reset_counter); data.abnormal_reset_counter = 0; save_device_bootinfo(&data); } } /* --- Crash / watchdog detection --- */ if ((bootmode_sw & 0x2000000) || (boot_cause & 2)) { syslog(6, "crash or wtd reboot\n"); if (ret && data.start_mode == APP) { data.crush_flag = 1; save_device_bootinfo(&data); } clear_sw_bootflag(0x2000000); if (!fs_mounted) mount_fs(0); save_crush_log(); } else { if (bootmode_sw & 0x100000) { syslog(6, "factory reset\n"); mount("/dev/nand_data"); save_boot_mode_normal(); clear_sw_bootflag(0x100000); } else if (bootmode_sw & 0x800000) { syslog(6, "ota reboot\n"); data.start_mode = OTA; save_device_bootinfo(&data); clear_sw_bootflag(0x800000); } else { syslog(6, "normal reboot\n"); } } int start_mode = 0; /* --- OTA path --- */ if (data.start_mode == OTA) { syslog(6, "load ota bin\n"); if (load_fw_bin(&flash_ota)) { start_mode = 2; // OTA boot goto boot; } syslog(6, "load ota failed, jump to App\n"); } /* --- APP validation --- */ if (!validate_ap(&vela_ap)) { if (data.app_fault_counter > 4) { data.start_mode = FACTORY; data.start_submode = 4; } if (data.app_fault_counter != 255) data.app_fault_counter++; save_device_bootinfo(&data); } else if (data.app_fault_counter) { data.app_fault_counter = 0; save_device_bootinfo(&data); } /* --- Select boot target --- */ if ((data.start_mode & 0xFD) == 0) { syslog(6, "load factory bin\n"); start_mode = load_fw_bin(&vela_factory); } else { start_mode = 0; } boot: /* --- Cleanup FS --- */ if (fs_mounted) { umount("/system", 0); umount("/data", 0); fs_mounted = 0; } if (start_mode == 2) charger_key_reset(0); system_reset_state(); /* --- Jump to selected image --- */ int *entry = &vela_ap[8 * start_mode]; syslog(6, "jump to %s addr:0x%lx\n", (const char *)entry[7], (entry[1] + 16) | 1); int args = get_start_args(); // jump to app entry ((int (__fastcall *)(int))((entry[1] + 0x10) | 1))(args); /* --- Stack protection --- */ if (stack_check_val != stack_chk) panic_veneer(); return 0; }
Загрузчик при старте инициализирует flash, выводит описание в консоль, читает состояние загрузки, конфигурацию и дальше выбирает что грузить из 3 режимов:
APP - основной режим работы
FACTORY - режим рекавери
OTA - режим OTA обновления
Я нашел пины UART консоли на плате, процесс стал более понятен, вот что в логе когда происходит нормальная загрузка
[bl] bootloader start ... [bl] SER_FLASH_IF init [bl] SER_FLASH init finish(1024 1024)! [bl] ****************Bootloader start!**************** [bl] **Software Version bl:[3.100.038] ap:[3.100.138] [bl] **Customer Version : 3.100.038 [bl] **SecureBoot Status : [false] [bl] **Build at:Jan 9 2026-15:27:30 [bl] **By longcheer shanghai R&D [bl] ****************************************** [bl] bootmode sw 0x80010030 boot_cause:0x4 read_ret:1 [bl] normal reboot [bl] Application check: ok [bl] jump to Application addr:0x2c080011
и вот что, когда приложение OTA падает в ошибку
[bl] bootloader start ... [bl] SER_FLASH_IF init [bl] SER_FLASH init finish(1024 1024)! [bl] ****************Bootloader start!**************** [bl] **Software Version bl:[3.100.038] ap:[3.100.138] [bl] **Customer Version : 3.100.038 [bl] **SecureBoot Status : [false] [bl] **Build at:Jan 9 2026-15:27:30 [bl] **By longcheer shanghai R&D [bl] ****************************************** [bl] bootmode sw 0x8a210030 boot_cause:0x4 read_ret:1 [bl] crash or wtd reboot [bl] mount /system [bl] mount /data [bl] crash happend !!! save log to /data/log/crash.txt [bl] crash in psram 0x3c3cd840 [bl] save log len:131064 [bl] load ota bin [bl] jump to OTA addr:0x3b800011
и при ошибке OTA приложения, bootloader просто не обрабатывает эту ситуацию, если посмотреть в код выше, счетчик считается только в режиме загрузки APP, режим OTA выключается самим загрузчиком OTA в конце обновления.
Что же приводит к такой ситуации, дело в том, что у часов есть 3 версии прошивок, CN - китайская, GL - глобальная, DEMO - демонстрационная версия для витрин магазинов, которая предназначена для утилизации в конце срока использования.
Системная партиция имеет размер 200Мб, и практически все прошивки имеют ресурсы впритык этому размеру, более того, некоторые файлы имеют разные имена, а OTA загрузчик сначала удаляет обновляемый из своего списка ресурс, а потом его копирует, и тут возникает проблема, место закончилось, попытка обновления OTA пакета приводит к фатальному завершению приложения. Режим загрузки остается OTA, и бутлоадер не защищает часы от сбойной загрузки.
Выводы из исследования проблемы
Итак, что плохо в данных решениях:
Если у вас возникла мысль, что разработчики намеренно заложили такой механизм, то у меня пару аргументов, что это вряд ли могло быть так:
в любом случае часы выглядят трупом - это гарантийный возврат, потеря денег и репутации компанией
в Redmi Watch 6 полностью переделали режим обновления системной партиции, а режим восстановления содержит бэкап основного приложения APP, кстати, самый лучший механизм восстановления на сегодня это у Mi Band 10.
В данной модели в качестве файловой системы используется yaffs2, хотя системная партиция работает в режиме readonly, зачем? Может быть для релоцирования bad блоков с помощью yaffs2 драйвера. Как раз в следующей модели /system - это просто romfs, он тупо пишется командой dd (команда чтения/записи блочных устройств), проверка на размер элементарная, партиция либо входит в лимит, либо нет. Здесь же работает пофайловое обновление с откатом, если новый файл не проходит валидацию crc32.
В архитектуре заложено 2 типа OTA пакетов, полное и инкрементальное, причем обновление практически всегда выполняется полным пакетом, OTA прекрасно знает, что он обновляет, соответственно, было бы логичным удалить все файлы ресурсов и установить их заново.
Фатальное завершение OTA не должно приводить к неконтролируемому результату, родной бутлоадер к этому совершенно не готов.
Решение проблемы
Решение опять же довольно тривиальное, нужно исправить проверку abnormal_reset только для режима APP.
if (data.start_mode == APP) на if (data.start_mode != FACTORY)
/* --- Abnormal reset handling --- */ if (data.start_mode != FACTORY) { if (bootmode_sw & 0x8000000) { syslog(6, "abnormal_reset %d", ++data.abnormal_reset_counter); if (data.abnormal_reset_counter > 5) { data.start_mode = FACTORY; data.start_submode = 3; data.abnormal_reset_counter = 0; } save_device_bootinfo(&data); clear_sw_bootflag(0x8000000); } else if (data.abnormal_reset_counter) { syslog(6, "clean abnormal_reset %d", data.abnormal_reset_counter); data.abnormal_reset_counter = 0; save_device_bootinfo(&data); } }
В результате bootloader прекрасно справляется с этой ситуацией
[bl] bootloader start ... [bl] SER_FLASH_IF init [bl] SER_FLASH init finish(1024 1024)! [bl] ****************Bootloader start!**************** [bl] **Software Version bl:[3.100.038] ap:[3.100.138] [bl] **Customer Version : 3.100.038 [bl] **SecureBoot Status : [false] [bl] **Build at:Jan 9 2026-15:27:30 [bl] **By longcheer shanghai R&D [bl] ****************************************** [bl] bootmode sw 0x8a210030 boot_cause:0x4 read_ret:1 [bl] abnormal_reset 6 [bl] crash or wtd reboot [bl] mount /system [bl] mount /data [bl] crash happend !!! save log to /data/log/crash.txt [bl] crash in psram 0x3c3cd840 [bl] save log len:681212 [bl] load factory bin [bl] jump to Factory addr:0x3b800011
После 5ти неудачных падений бутлоадер переключил загрузку на режим рекавери, часы успешно загрузились, дальше рекавери отформатировал раздел /data и часы прекрасно запустились.
Отладка таких вещей лежит на совести разработчиков конечно, и это не первые Xiaomi часы с такое же проблемой, Mi Band 9 Pro падает прям 1в1, поэтому будьте внимательны к тому, что загружаете в ваши часы, иначе готовьтесь к сюрпризам.
Всем удачных обновлений и хорошего рекавери.
D
kenomimi
Для часов дают исходники прошивки?
NutsUnderline
ну для некоторых на самом деле да . а для некоторых выводят пины swd и крутись как хочешь :)