HP Prime G2 под операционной системой Windows 10 IoT

О запуске Windows на стандартном калькуляторе можно было только мечтать до появления HP Prime G2. Ещё никогда на рынок не выходил калькулятор на таком мощном железе. И что ещё более важно, HP выбрала процессор ARMv7-A! В этой статье обсудим, как установить на устройство UEFI и ACPI.


Спецификации SoC на HP Prime G2. В SoC NXP i.MX 6ULL (Ultra Lite) установлен одноядерный процессор Cortex А7

Предыдущие работы

Мой друг Вэньcинь Чжан (Zephray) сделал фундаментальную работу по обратной разработке GPIO и технических характеристик калькулятора. Кроме того, ему удалось портировать на калькулятор рабочую U-Boot и Linux.

Согласно TI-Planet, в калькуляторе предусмотрено большое количество тестовых пинов, включая SD/MMC, JTAG и UART.

Сара (winocm) изучила возможность запуска Windows RT на платформе Qemu. К 2019 году кое-что изменилось, но статья не потеряла своей ценности.

Microsoft заключила соглашение NXP, чтобы обеспечить поддержку Windows 10 IoT на микросхемах iMX SoC. Таким образом, технически Windows 10 IoT должна работать на этом калькуляторе (как и вообще, Windows на ARM).

Уточняем системные требования Windows

Системные требования для запуска ОС семейства Windows 10 указаны на сайте Microsoft Docs. Даже самые минимальные требования больше, чем у Linux: системе нужен процессор x86/x64/ARMv7/AArch64, по крайней мере 256 МБ памяти и 2 ГБ на диске. Требуется функциональная прошивка UEFI, полные таблицы ACPI и SMBIOS.

В нашем случае на устройстве недостаточно места (и Windows также не поддерживает Raw SLC NAND), но к калькулятору можно подключить загрузочное устройство по USB.

Сара перечисляет архитектурные требования к ARMv7 для запуска Windows. За прошедшие годы требования немного изменились, вот как они выглядят на данный момент:

Системный процессор: ARMv7-A совместимый процессор с VFPv3+VFP HalfPrec, VFPv4 также подойдёт
Память: минимум 256 МБ RAM (вероятно, можно и меньше)
Периферийные устройства:
    - Системный таймер (или по архитектуре, или от вендора)
    - ARM Generic Interrupt Controller (GIC) или Broadcom Interrupt Controller на BCM2835/2836/2837, наличие CPU и Distributor Interface. Если в системе присутствует и декларируется GIC, требуется GICv2 иои выше
    - Фреймбуфер
    - Поддержка UART, или NS16550, BCM283x, или от вендора (в случае Qualcomm и NXP)
    - Прошивка: UEFI 2.3 или выше

Наш калькулятор соответствует этим жёстким требованиям. Однако SoC по умолчанию работает на 396 МГц, это меньше базового уровня 400 МГц/1 ГГц. Также сообщается о 250 МБ системной памяти, в то время как минимальное требование для системы с UI составляет 512 МБ. Но она загружается!


По данным cpuinfo из WinDbg, SoC работает на частоте 396 МГц

Думаю, можно ещё сильнее сократить требования. Если я правильно помню, Windows Server Nano хватает около 150 МБ памяти для загрузки на системах amd64.

UEFI и ACPI

Я уже несколько раз писал о реализациях UEFI, так что здесь ничего нового. В основном UEFI состоит из набора драйверов устройств и компонентов ядра TianoCore. Таблицы ACPI копируются из репозитория Windows IoT iMX Project Mu и урезаются.

UEFI загружается из U-Boot. iMX по умолчанию не разрешает доступ к невыровненной памяти, и это вызывает много проблем на этапах UEFI DXE и BDS, так что следует включить его как можно раньше.

 mrc   p15, 0, r0, c1, c0, 0
 bic   r0, r0, #2
 mcr   p15, 0, r0, c1, c0, 0

Компилятор с аппаратной поддержкой float ускоряет загрузчик примерно с 30 до 4 секунд. На платформах ARMv7 Windows заявляет поддержку VFPv3+.

Инициализация экрана, а также некоторые назначения I/O mux выполняются в U-Boot. Сейчас U-Boot не поддерживает интерфейс 24/32bpp Serial RGB LCD, поэтому я добавил поддержку Serial RGB через реализацию фреймбуфера iMX в ядре Linux. Код ещё не в мастере, но я позже передам его туда.



Кажется, LCD работает. Вся процедура:

1. Запустить uboot.
   
2. Найти пин для подсветки экрана.
   
3. Найти пин для SPI и последовательность инициализации LCD.
   
4. Найти пин I2C и настроить PMIC через I2C для правильного напряжения.

Демонстрация работы интерфейса Serial RGB LCD в U-Boot

UEFI просто берёт фреймбуфер, выделенный U-Boot, и регистрирует протокол вывода графики Graphics Output Protocol. К сожалению, разрешение экрана не удовлетворяет минимальным требованиям консоли 80*25, поэтому я изменил компоненты Console DXE, добавив новый режим 40*12.


Компонент EDK2 утверждает, что разрешение экрана не соответствует минимальным требованиям консоли 80*25

Перед хаком компонентов консоли я сделал небольшой трюк, зарепортив разрешение 640*480 в протокол UEFI GOP. Трюк также помог получить диагностическую информацию из Диспетчера загрузки Windows, потому что разрешения 320*240 недостаточно для отображения кода ошибки. Я периодически запускаю из фреймбуфера block-transfer (BLT) в файловую систему и сохраняю BMP-файлы на USB-накопителе.


Хак делает доступным режим 80*25 с некоторыми графическими артефактами

После подключения нового режима качество изображения значительно улучшается.


Режим 40*12


Режим 40*12

Вот как выглядит сообщение диспетчера загрузки Windows на разрешении 320*240:



Первая попытка терпит неудачу ещё на этапе служб загрузки UEFI. Из-за маленького экрана не виден код ошибки.


Block-transfer (BLT) из фреймбуфера позволяет сохранить сообщение в графический файл и прочитать его

По поводу поддержки USB. К счастью, USB в iMX6 полностью соответствует стандарту, а поддержка включена в последние версии Windows. Поэтому, как только я настроил контроллер OTG в режим хоста и передал область MMIO в UEFI и Windows, он волшебно работает без проблем. Но мы не нашли VBus на порту OTG (предполагаем, что там какая-то схема DC-DC, управляемая SoC или PMIC, но это лишь непроверенная гипотеза), поэтому для корректной работы порт нужно запитывать через некий внешний источник.

SMBIOS

Убедитесь, что правильно сообщаете в SMBIOS размер памяти и адресные области, или Windows начнёт вытворять невероятно странные вещи (tm).


Отладчик Windows не может считать память из-за неправильной конфигурации SMBIOS

Таймер и расширения HAL

Кажется, мы справились с конфигурацией памяти (LPAE), но наверняка появится какая-то другая проблема. О да…



Итак, загрузка Windows пока доходит только до этого этапа.


Если не найден подходящий системный таймер, Windows обращается к некоему предполагаемому и недопустимому адресу памяти

Windows не загрузится, если не найден контроллер прерываний или системный таймер. Системное время можно зарегистрировать с помощью таблицы GTDT (таблица архитектуры ARM) или расширений HAL через таблицу CSRT.

iMX6ULL поставляется с тремя таймерами: iMX GPT (Generic Purpose Timer), EPIT (Enhanced Periodic Timer) и ARM Architectural Timer. Последний появился только в iMX6UL/ULL, тогда как предыдущие системы iMX6 SoC работали на старых ядрах вроде Cortex A15 без поддержки архитектурного таймера. Microsoft реализовала для системного таймера расширение EPIT HAL, но оно сначала не загружалось из-за несоответствия идентификатора оборудования в таблице CSRT и системном образе (я загрузил более ранний FFU для iMX6 Solo). Поэтому когда таймер недоступен, Windows будет отчаянно пытаться инициализировать предполагаемый таймер, и система упадёт из-за недопустимого доступа к памяти.

В документации iMX6ULL упоминается архитектурный таймер, но без подробностей о процедуре инициализации. Счётчик таймера можно инициализировать кодом EDK2, но GIC PPI (Per Processor Interrupt) не будет корректно работать. Однако Windows успешно инициализирует и использует таймер через таблицу GTDT.

В данный момент UEFI использует таймер EPIT и отключает его при передаче в Windows. В свою очередь, Windows инициализирует таймер GPT. В какой-то более поздний момент UEFI тоже может переключиться на GPT с надлежащей процедурой инициализации.

Некоторым периферийным устройствам требуется расширение HAL для контроллера Smart DMA (SDMA), его не слишком трудно загрузить.

Покажи, как это работает!

[Security] 3rd party image[0] can be loaded after EndOfDxe: VenHw(0D51905B-B77E-452A-A2C0-ECA0CC8D514A,004118020000000000)/USB(0x0,0x0)/USB(0x2,0x0)/HD(1,GPT,F9ADAEA9-E8DE-4291-B191-5DABA6DC1215,0x800,0x100000)/\efi\boot\bootarm.efi.
 InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 8F257028
 ConvertPages: failed to find range 10000000 - 100EEFFF
 Loading driver at 0x0008E9D6000 EntryPoint=0x0008E9E7511 bootmgfw.efi
 InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 8F28EB10
 ProtectUefiImageCommon - 0x8F257028
 0x000000008E9D6000 - 0x00000000000EF000
 InstallProtocolInterface: 752F3136-4E16-4FDC-A22A-E5F46812F4CA 8FBFF88C
 ConvertPages: failed to find range 102000 - 102FFF
 Disabling EPIT timer on ExitBootServicesEventSetUefiImageMemoryAttributes - 0x000000008F78A000 - 0x0000000000003000 (0x0000000000000008)
 SetUefiImageMemoryAttributes - 0x000000008F787000 - 0x0000000000003000 (0x0000000000000008)
 SetUefiImageMemoryAttributes - 0x000000008F784000 - 0x0000000000003000 (0x0000000000000008)
 SetUefiImageMemoryAttributes - 0x000000008F77F000 - 0x0000000000005000 (0x0000000000000008)
 SetUefiImageMemoryAttributes - 0x000000008F77C000 - 0x0000000000003000 (0x0000000000000008)
 SetUefiImageMemoryAttributes - 0x000000008F779000 - 0x0000000000003000 (0x0000000000000008)

Если интересно, насколько медленно это загружается, то около трёх с половиной минут.

Видео на ускоренной скорости 2х:

Где Secure Boot и TPM?

На самом деле это необязательно. Но поскольку OP-TEE поддерживает iMX6/7/8, вы можете запустить Secure Monitor в TrustZone (TZ) и реализовать эти сервисы через вызовы (Secure Monitor Calls) от EL1/PL1.

На самом деле официальная реализация iMX Windows IoT поставляется с OP-TEE, но я её проигнорировал ради экономии памяти.

Что насчёт драйверов?

В репозитории Windows 10 IoT BSP лежит множество драйверов для iMX6/7/8. Драйвер USB работает из коробки, как уже упоминалось. Для калькулятора нужны ещё драйверы тачскрина и клавиатуры.

Они доступны в дереве ядра Linux, так что не должно быть слишком сложно портировать их на Windows.

Можно ли загрузить Windows RT 8.1?

Возможно. Обновление: Windows RT 8.1 не загрузится, только более поздние версии. Windows PE не загрузится в режиме ramdisk, поскольку 256 МБ памяти недостаточно. Мне не удалось запустить режим flat boot, после перечисления устройств (включая USB-накопитель) он входит в какой-то цикл без дальнейшей инициализации.


HP Prime G2 загрузил Windows, которая запустила приложение калькулятора


Блокнот на калькуляторе


Блокнот на калькуляторе пытается отправить текст на печать

Но я хочу загрузить Linux тоже!

Есть два варианта:

• Просто использовать U-Boot для загрузки zImage, дерева устройств и initrd.
  
• Переместить области памяти FD, MpPark и FrameBuffer в верхнюю часть системной памяти, оставив свободными 128 МБ в нижней области памяти.

Загрузите Linux через GRUB или непосредственно из EFISTUB. Всё нормально загружается, вот фрагмент лога:

EFI stub: Exiting boot services and installing virtual address map…
 Disabling EPIT timer on ExitBootServicesEventSetUefiImageMemoryAttributes - 0x000000008F97B000 - 0x0000000000003000 (0x0000000000000008)
 SetUefiImageMemoryAttributes - 0x000000008F978000 - 0x0000000000003000 (0x0000000000000008)
 SetUefiImageMemoryAttributes - 0x000000008F973000 - 0x0000000000005000 (0x0000000000000008)
 SetUefiImageMemoryAttributes - 0x000000008F970000 - 0x0000000000003000 (0x0000000000000008)
 SetUefiImageMemoryAttributes - 0x000000008F96D000 - 0x0000000000003000 (0x0000000000000008)
 SetUefiImageMemoryAttributes - 0x000000008F96A000 - 0x0000000000003000 (0x0000000000000008)
 Booting Linux on physical CPU 0x0
 Linux version 4.14.98-g371433a62906-dirty (imbushuo@bc-macbookpro) (gcc version 7.4.1 20181213 [linaro-7.4-2019.02 revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] (Linaro GCC 7.4-2019.02)) #2 PREEMPT Thu Nov 14 03:10:29 EST 2019
 CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c53c7d
 CPU: div instructions available: patching division code
 CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
 OF: fdt: Machine model: HP Prime G2 Calculator
 Memory policy: Data cache writeback
 efi: Getting EFI parameters from FDT:
 efi: EFI v2.70 by EDK II
 efi:  ACPI 2.0=0x8f49b000  SMBIOS=0x8f9a8000  SMBIOS 3.0=0x8f9a6000
 OF: reserved mem: failed to allocate memory for node 'linux,cma'
 CPU: All CPU(s) started in SVC mode.
 Built 1 zonelists, mobility grouping on.  Total pages: 64516
 Kernel command line: zImage.efi root=/dev/ram0 rw initrd=/rootfs.cpio.gz dtb=/imx6ull-14x14-prime.dtb

Если вы используете конфигурацию NXP Linux, это приведёт к сбою ядра, потому что она читает адрес памяти initrd из дерева устройств или некоторых предопределённых параметров конфигурации, и, конечно же, initrd загружается где-то ещё в UEFI. Необходимо удалить эти параметры и сделать конфигурацию более универсальной.

Но зачем?

Люди говорят о запуске Windows на разных устройствах, поэтому я хочу троллить их до конца года.

Как насчёт других проектов? Что дальше?

Работа продолжится. Нужно ещё реализовать некоторые драйверы, добиться загрузки UEFI со встроенной NAND, реализовать удобный для калькулятора пользовательский интерфейс загрузки UEFI и изучить возможность загрузки стоковой операционной системы HP PPL из моей UEFI.