Статья описывает загрузку процессоров 905х2, А113х установленные я Яндекс Станциях, поэтому рассматривается только режим SecureBoot (безопасная загрузка).
В сети много интересного находится по фразе "Amlogic Boot flow", например статья из Китая.
Для определения причин поломки и анализа поведения устройств на базе процессоров Amlogic нужно подробнее проникнуть в некоторые аспекты старта системы(загрузки).Старт происходит в несколько этапов:
- Запуск Bootrom
- Поиск и проверка первичного загрузчика (BL2)
- Старт первичного загрузчика(BL2), который инициализирует оперативную память, загружает и проверяет U-boot(BL33).
- Запуск U-boot (BL33) с дальнейшей загрузкой уже основной системы
В этапе 2 до старта BL33 еще происходит загрузка системы безопасности Trusted Firmware: BL31, BL32.
Теперь опишу подробнее все этапы загрузки.
1.BootROM - BL1
Вшитая во внутреннюю ROM (read-only memory) память процессора программа, стереть ее не возможно как и изменить. Запуск BL1 происходит при подачи питания на процессор, загрузка и выполнение идет во внутренней оперативной памяти процессора SRAM, внешние микросхемы памяти не требуются. После запуска BL1 проводит минимальную настройку для поиска и загрузки следующего этапа BL2.
В качестве источника загрузки BL2 могут использоваться :
- SPI NOR, SPI NAND
- NAND
- SD
- EMMC
- USB (флешка или из специального ПО с компьютера)
Алгоритм загрузки по очереди перебирает источники пока не встретит подходящий, в противном случае происходит возврат к началу и для повторного поиска - LOOP.
Последовательность поиска источника можно изменять в зависимости от состояния битов POC (физические входы процессора BOOTx) . Таблица последовательности приведена например в документации к U-boot
Привожу два пример с различными битами POC:
AXG:BL1:d1dbf2:a4926f;FEAT:F0DC31BE:2000;POC:F;EMMC:800;NAND:81;SD:0;READ:0;0.0;0.0;CHK:0;
AXG:BL1:d1dbf2:a4926f;FEAT:F0DC39BE:2000;POC:D;USB:0;EMMC:800;NAND:81;SD:400;
Из примера видно что при POC:F - первым проверяется источник на emmc, а при POC:D перым проверяется USB.Сделано это для возможности включения сервисных режимов - например прошивки через USB или загрузка с SD карты для восстановления загрузчика.
После того как источник найдет BL1 загружает во внутреннюю ОЗУ процессора BL2 и начинает его расшифровку и проверку.
2.BL2
Производит поиск доступной внешней ОЗУ и ее настройку. Как только память настроена BL2 загружает и расшифровывает TPL. TPL включает в себя таблицу FIP и последующие части Trusted Firmware : BL31, BL32 и U-boot (BL33) - все вместе BL3x. Таблица FIP содержит данные о расположении каждой из частей загрузчиков BL3x и на некоторые служебные данные.
Перед загрузкой FIP, BL3x логика BL2 проводит проверку подписи RSA и далее на основании ее проверяется целостность загруженной части. Любой измененный байт повлечет сбой и устройство не загрузится.
3.BL3x
Если проверка проходит успешно то загружаются оставшиеся части загрузчика BL31,32,33. Последний из списка U-boot он отвечает за дальнейший запуск ядра (kernel) из раздела boot. Прежде чем оно запустится его расшифровывает и проверяет BL31, ядро так же подписано и если оно не прошло проверку то прерывание загрузки и ребут. Успешный запуск отражается в консоли следующим сообщением
aml log : R1024 check pass!
aml log : R-1024 check pass!
aml log : R1024 check pass!
uboot time: 3858442 us
В этой цепочке первым заводится BL31 - Secure Monitor и он останется жить и работать дальше пока устройство включено, он обеспечивает доступ обычной системы к разрешенной части защищенных данных ( normal word, secure word). Как только BL31 загрузился и подготовил систему он приступает к загрузке BL33(U-Boot) и BL32(OPTEE), перед этим производится проверка их подписи и для BL33 идет процесс распаковки (он упакован в LZ4HC).
BL32 нас слишком не касается как пользователей, оно обеспечивает функционирование защищенного хранилища различных системных и пользовательских данных, тот самый кто шифрует файлы пользователя (потом в дампе их нельзя открыть). Он же является причиной невозможности замены флешки устройства просто так. Для Яндекс колонок такая операция приведет к тому что невозможно добавить колонку в умный дом.
Процесс загрузки от FIP до U-Boot
Load FIP HDR from NAND, src: 0x0000c000, des: 0x01700000, size: 0x00004000, part: 0
Load BL3x from NAND, src: 0x00010000, des: 0x01704000, size: 0x000e4000, part: 0
bl2z: ptr: 0512b398, size: 00001dd8
NOTICE: BL31: v1.3(release):704e60a
NOTICE: BL31: Built : 15:38:40, Dec 13 2018
NOTICE: BL31: AXG secure boot!
NOTICE: BL31: BL33 decompress pass
[Image: axg_v1.1.3372-f39eea9 2018-12-20 15:11:36 jenkins@walle02-sh]
OPS=0x43
25 0b 43 00 15 fb d8 5f b6 15 36 8c 08 72 ce 20
bl30:axg ver: 9 mode: 0
bl30:axg thermal0
[0.015847 Inits done]
secure task start!
high task start!
low task start!
INFO: BL3-2: ATOS-V2.4-214-g878b640 #1 Mon Feb 25 10:59:59 UTC 2019 arm
INFO: BL3-2: Chip: AXG Rev: B (25:B - 40:2)
INFO: BL3-2: crypto engine DMA
INFO: BL3-2: secure time TEE
INFO: BL3-2: CONFIG_DEVICE_SECURE 0xb200000e
U-Boot 2015.01 (Sep 29 2023 - 16:13:15)
DRAM: 256 MiB
Relocation Offset is: 0eda0000
Подходим к BL33 U-Boot. Он выполняется в небезопасном мире (Normal Word), а значит не может иметь доступ к критичной информации без разрешения BL31 или BL32. Его функция на основании скриптов Enviroment произвести:
- загрузку Ядра (kernel),
- Дерева устройств (device tree - dtb),
- ramdisk,
- настроить переменные окружения запускаемой системы
- перевести систему в режим восстановления recovery (при этом грузится отдельное ядро , обычно из раздела recovery)
NAND: get_sys_clk_rate_mtd() 270, clock setting 200!
NAND device id: 98 da 90 15 76 16
NAND device: Manufacturer ID: 0x98, Chip ID: 0x98 (Toshiba A revision NAND 2Gib TC58NVG1S3HBAI4 )
Когда ядро и его части загружены U-Boot инициирует их проверку и расшифровку , для этого обратившись к BL31 и указав адреса где лежит исходное и куда положить расшифрованное. В случае успеха вызывается команда bootm и происходит старт основной системы, например Android.
Don't have any recovery requests, skip...
[imgread]szTimeStamp[2025012020574616]
[imgread]secureKernelImgSz=0x582000
aml log : R-1024 check pass!
aml log : R1024 check pass!
avb2: 0
save_power_post ...
avb2: 0
## Booting Android Image at 0x03080000 ...
load dtb from 0x1000000 ......
Amlogic multi-dtb tool
fdt_addr: 0x01000000
Single dtb detected
loaded dtb to 0x1000000 ......
Uncompressing Kernel Image ... OK
kernel loaded at 0x01080000, end = 0x01d26a00
Loading Device Tree to 000000000eb81000, end 000000000eb8d794 ... OK
Starting kernel ...
uboot time: 3816525 us
[ 0.000000@0] Booting Linux on physical CPU 0x0
[ 0.000000@0] Linux version 4.9.68 (sandbox@sandbox7112-18-04-4231491203-0) (gcc version 6.3.1 20170109 (Linaro GCC 6.3-2017.02) ) #1 SMP PREEMPT Mon Jan 20 20:55:30 MSK 2025
[ 0.000000@0] Boot CPU: AArch64 Processor [410fd034]
4.Заключение
На этом собственно все. Заключительно скажу, что вмешаться в процесс загрузки не так просто, все части подписаны RSA который подделать не выйдет, нарушение любого из этапов сломает загрузку и устройство не запустится. По этой причине просто так нельзя запустить например Арамбиан или Ubuntu.
aml log: no key found ...
aml log : fail with 1151aml log: no key found ...
aml log : fail with 1151aml log : R-1024 check pass!
aml log : R1024 check pass!
uboot time: 3560208 us
domain-0 init dvfs: 4
bl31 reboot reason: 0xd
bl31 reboot reason: 0x1
system cmd 1.
AXG:BL1:d1dbf2:a4926f;FEAT:F0DC31BC:2000;POC:D;USB:0;EMMC:800;NAND:0;READ:0;0.0;0.0;CHK:0;
Пример поломанной загрузки