Разбираюсь с очередной моделью 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