Разбираюсь с очередной моделью 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
ссылка на оригинал статьи https://habr.com/ru/articles/1027516/