Random Internet search gives you useful results: https://lore.kernel.org/linux-arm-msm/1576752109-24497-7-git-send-email-sricharan@codeaurora.org/
With some induction, we can guess the GICH/GICV and vGIC maintenance interrupt for other QGIC2 SoC like MSM8994:
[04Ch 0076 8] Base Address : 00000000F9002000 [054h 0084 8] Virtual GIC Base Address : 00000000F9004000 [05Ch 0092 8] Hypervisor GIC Base Address : 00000000F9001000 [064h 0100 4] Virtual GIC Interrupt : 00000019
Running Windows on a consumer calculator was a dream until the appearance of HP Prime G2 Graphing Calculator. This calculator has the most superior hardware specification among the market so far. And more importantly, HP switched to ARMv7-A on the calculator (!)
My friend Wenting Zhang (Zephray) has done the fundamental reverse engineering about GPIO assignments and technical information regarding this calculator. In addition, he managed to port a functional U-Boot and Linux on it.
According to TI-Planet, the calculator comes with a lot of test pins including SD/MMC, JTAG and UART.
Sarah (winocm) explored the possibility of running Windows RT on Qemu platform. Some information has been changed as of 2019, but the post is still worth reading.
Microsoft also partnered with NXP to enable Windows 10 IoT on iMX SoCs. Given these facts, this calculator should be technically capable of running Windows 10 IoT (or generically saying Windows on ARM.)
Microsoft Docs site outlined the system requirements for the Windows 10 family. To run the small footprint (still large compared to Linux), the system should have a x86/x64/ARMv7/AArch64 processor, at least 256MB memory and 2GB storage. The device should also has a functional UEFI firmware and full ACPI & SMBIOS tables.
There isn’t sufficient onboard storage in this case (and Windows doesn’t support raw SLC NAND flash either), but USB device can be attached to the calculator and acts as a boot device.
Sarah has summarized ARMv7 architectural requirements for running Windows. The requirements have changed a bit across years, so here is my new summary on this:
System processor: ARMv7-A compatible processor with VFPv3+VFP HalfPrec, VFPv4 is also okay
Memory: At least 256MB of RAM (can probably do less)
Peripherals:
- System timer (either architectural or vendor-specific)
- ARM Generic Interrupt Controller (GIC) or Broadcom Interrupt Controller on BCM2835/2836/2837, both CPU and Distributor Interface. GICv2 or higher is required if GIC is present and declared.
- Framebuffer
- Supported UART, either NS16550, BCM283x or some vendor-specific IP (in the case of Qualcomm and NXP)
- Firmware: UEFI 2.3 or higher
In this case the calculator meets those hard requirements. However the SoC runs in 396MHz by default, significantly slower than the 400MHz/1GHz baseline. Also I only report about 250MB memory to the system while the minimum requirement is 512MB with user interface. However, it boots!
I think we can probably further push the limit. If I recall correctly, Windows Server Nano requires about 150MB memory to boot on amd64 systems.
I’ve talked about UEFI implementations several times in the past so there isn’t anything new. Basically the UEFI consists a set of device drivers and core components from TianoCore. ACPI tables are copied from the Windows IoT iMX Project Mu Repo and stripped down.
I chainload the UEFI from U-Boot. iMX does not enable unaligned memory access by default and this causes a lot of troubles in UEFI DXE and BDS phases. You should enable it as soon as possible.
mrc p15, 0, r0, c1, c0, 0
bic r0, r0, #2
mcr p15, 0, r0, c1, c0, 0 Using a compiler with hardware float support is also helpful for speed up the boot speeed (30s -> 4s.) Also Windows mandates VFPv3+ support on ARMv7 platforms.
The screen initialization as well as some I/O mux assignments are completed in U-Boot. The current U-Boot does not support 24/32bpp Serial RGB LCD interface operation, so I added the Serial RGB support by referring the implementation of iMX FrameBuffer in Linux Kernel. The code has not yet been upstreamed to the master but I should do this later.
UEFI just picks up the FrameBuffer allocated by U-Boot and registers the Graphics Output Protocol. Unfortunately the screen resolution cannot satisfy the minimum 80*25 console requirements, so I patched Console DXE components by adding a new 40*12 mode.
Prior to the hack in console components I did some trick by reporting 640*480 output in the UEFI GOP protocol. The trick also helped me getting diagnostics information from Windows Boot Manager because 320*240 isn’t sufficient to display the error code. I periodically run block-transfer (BLT) from FrameBuffer to the filesystem and saved BMP files on a USB drive.
As for USB support, fortunately the USB IP in iMX6 is fully standard-compliant and in-box support is included in recent Windows versions. Therefore once I configured the OTG controller into host mode and pass the MMIO region to UEFI and Windows, it works magically without problems. However, Wenting and me have not yet figured out the VBus source on the OTG port (we assume some DC-DC circuit that controlled by SoC or PMIC but this hypothesis has not yet been verified) so the port has to be powered using some external voltage source for proper functionalities.
Make sure you properly report memory size and address regions in SMBIOS, or Windows will do some incredibly weird things (TM).
Windows will fail to boot if no Interrupt Controller or System Timer is found. A system time can be registered using either GTDT table (ARM architectural table) or HAL extensions via CSRT table.
iMX6ULL comes with three timer complexes: iMX GPT (Generic Purpose Timer), EPIT (Enhanced Periodic Timer) and ARM Architectural Timer. ARM Architectural Timer is new to iMX6UL/ULL since earlier iMX6 SoCs use cores such as Cortex A15 which lacks proper Architectural Timer support. Microsoft has implemented a EPIT HAL extension for the system timer, but it was not loaded at first due to a hardware ID mismatch in CSRT table and system image (I downloaded an earlier FFU for iMX6 Solo.) So in the case when no timer is available, Windows will desperately attempt to initialize an assumed timer and the system crashes due to invalid memory access.
The iMX6ULL datasheet does mention the presence of architectural timer but doesn’t say much about the initialization procedure. The EDK2 code can initialize the timer counter but GIC PPI (Per Processor Interrupt) does not work properly. However, Windows successfully initializes and utilizes the timer via GTDT table.
At this moment the UEFI utilizes EPIT timer and turns it off upon the hand-off to Windows. Windows picks up the generic timer and initializes it then. At some later point the UEFI might switch to generic timer too, with the proper initialization procedure.
A few peripherals needs the Smart DMA (SDMA) controller HAL extension and it isn’t too hard to load it.
[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)
There are not really necessary. However, since OP-TEE has iMX6/7/8 support, you can run a secure monitor in TrustZone (TZ) and provide those services via Secure Monitor Calls from EL1/PL1.
In fact the official iMX Windows IoT implementation comes with OP-TEE bundled. I skipped it due to the concern of memory utilization.
Windows 10 IoT BSP repository have a lot of available iMX6/7/8 driver sources available. USB works out of box as mentioned. The calculator touchscreen and keypad drivers need to be implemented.
The touchscreen and keypad drivers are available in the Linux kernel tree so it should not be too hard to port them on Windows.
Maybe. Update: Windows RT 8.1 won’t boot, but later versions do. Windows PE won’t boot in ramdisk mode because 256MB memory isn’t sufficient. I haven’t got flat boot mode work, it enters some loop with no further initialization once devices are enumerated (including the USB drive I used.)
You have two options:
Load Linux via either GRUB or directly from EFISTUB. It boots and here’s a snippet of the boot log:
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
If you are using the NXP Linux configuration, it will eventually panic because it reads initrd memory address from device tree or some predefined configuration settings and of course the initrd is loaded as somewhere else in UEFI. You need to remove those settings and make the configuration more generic.
People talk about running Windows on random devices so I want to troll them by the end of the year.
They will continue. So far, I need to implement more drivers, enable UEFI boot from on-board NAND, implement a calculator-friendly UEFI boot user interface and explore the possibility of booting stock HP PPL OS from my UEFI.
This project is partially derived from Microsoft’s Windows 10 IoT BSP for NXP SoC platforms. I would also like to thank Wenting for sending me his Prime G2 with UART lines soldered for debugging.
Recent Apple MacBook Pro models are usually equipped with long OLED touch display that officially named “Touch Bar” that substitutes the traditional Function (Fn) key row. Internally, this thing is called Dynamic Function Row (DFR) according to the naming prefix of related system components. In Boot Camp Windows installations, the Touch Bar acts as basic media and function keys without advanced graphical capabilities.
Given the fact that the Touch Bar is implemented by either Apple T1 or T2 chip, it is certain that one or more connection technology such as USB are utilized for the host communication. However, the communication protocol remains unknown for a long time due to the availability(cost) of device and the nature of typical technology users.
Third-party developers have developed applications that simulates Touch Bar on the host (x86) system. A quick inspection through the source code reveals a library that generates the continuous stream that contains the graphical content on the Touch Bar. It suggests that the content on Touch Bar is pre-rendered on the x86 system and gets transferred to the ARM side (T1/T2). Since T1 and T2 are both connected on the USB bus, packet captures were conducted over the USB bus.
During packet capture sessions, the pattern of periodic large packet transfers were observed. However, the size is not fully deterministic, but mostly it is larger than 54000 bytes. More image with certain patterns (single color, rainbow, etc.) were transferred to help analysis the binary structure. With sufficient samples, the following characteristics and structs were concluded:
typedef struct _DFR_GENERIC_REQUEST_CONTENT {
UINT32 RequestKey;
UCHAR Reserved[8];
UINT32 End;
} DFR_GENERIC_REQUEST_CONTENT, *PDFR_GENERIC_REQUEST_CONTENT;
typedef struct _DFR_GENERIC_REQUEST {
DFR_GENERIC_REQUEST_HEADER Header;
DFR_GENERIC_REQUEST_CONTENT Content;
} DFR_GENERIC_REQUEST, *PDFR_GENERIC_REQUEST;
typedef struct _DFR_UPDATE_FB_REQUEST_CONTENT {
UINT16 Reserved0;
UINT8 FrameId;
UINT8 Reserved1;
UINT32 Reserved2;
UCHAR Reserved3[24];
UINT16 BeginX;
UINT16 BeginY;
UINT16 Width;
UINT16 Height;
UINT32 BufferSize;
} DFR_UPDATE_FB_REQUEST_CONTENT, *PDFR_UPDATE_FB_REQUEST_CONTENT;
typedef struct _DFR_UPDATE_FB_REQUEST {
DFR_GENERIC_REQUEST_HEADER Header;
DFR_UPDATE_FB_REQUEST_CONTENT Content;
} DFR_UPDATE_FB_REQUEST, *PDFR_UPDATE_FB_REQUEST;
Last year I mentioned my attempt to bootstrap Windows 10 on Dragonboard 410c. This year I ported EDK2 to Nintendo Switch and successfully booted Windows 10 arm64 installation ramdisk (rs4, rs5, and 19H1 tested as of writing time). I will briefly introduce a common way to port EDK2 with existing codebase (e.g. U-Boot), as well as cases of booting in EL2 (hypervisor).
While this article applies to most ARM SoCs, the following content will use Tegra as the example. NVIDIA developed a few solutions for Windows on ARM in Windows 8 era: Tegra 3 (Tegra30) and 4 (Tegra114). No further model have official Windows BSP (Board Support Package) released publicly due to low market acceptance of those Windows RT products.
Despite of that, general AArch64 processors are capable to run Windows 10 without additional HAL extension library if the following conditions are satisfied:
One noticeable exception the initial generation of Qualcomm Kryo (Snapdragon 820, 821) due to the faulty cache design in large core cluster. Windows removed the required erratum for it due to the complication of patch maintenance.
In the case of Tegra X1, it satisfied all conditions outlined above. I used an old-bootrom Nintendo Switch as my experiment platform since it is much cheaper than Jetson TX1. Additionally, there is verified CoreBoot and U-Boot source code for these Tegra X1 devices including Nintendo Switch.
I assume you are familiar with the NVIDIA RCM Exploit (Fusee-Gelee) as well as Tegra Boot flow. If you are not familiar with Tegra Boot flow, please refer to Tegra Technical Reference Manual available on NVIDIA developer site.
There are a few environment assumptions that need to be addressed while porting U-Boot device/driver code to EDK2:
To save myself some time bootstrapping the microSD slot, I ported the clock and device framework from U-Boot to EDK2. Here are a few suggestions while porting U-Boot code to EDK2:
Device Tree is the de-facto standard in ARM to describe the system and peripheral hierarchy. Windows RT introduces the intensive use of ACPI on ARM platforms. I will cover some required tables for a success Windows startup on ARM platforms. For tables such as CSRT and DSDT, check out the Microsoft documentation.
For SoC with architecture timer, ARM defines GTDT table to describe platform timer information. In the device tree, an architectural timer may
timer {
compatible = "arm,armv8-timer";
interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
<GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
<GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
<GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
interrupt-parent = <&gic>;
};And it looks like this in ACPI GTDT table:
....
[024h 0036 8] Counter Block Address : FFFFFFFFFFFFFFFF
[02Ch 0044 4] Reserved : 00000000
[030h 0048 4] Secure EL1 Interrupt : 0000001D
[034h 0052 4] EL1 Flags (decoded below) : 00000002
Trigger Mode : 0
Polarity : 1
Always On : 0
[038h 0056 4] Non-Secure EL1 Interrupt : 0000001E
[03Ch 0060 4] NEL1 Flags (decoded below) : 00000002
Trigger Mode : 0
Polarity : 1
Always On : 0
[040h 0064 4] Virtual Timer Interrupt : 0000001B
[044h 0068 4] VT Flags (decoded below) : 00000002
Trigger Mode : 0
Polarity : 1
Always On : 0
[048h 0072 4] Non-Secure EL2 Interrupt : 0000001A
[04Ch 0076 4] NEL2 Flags (decoded below) : 00000002
Trigger Mode : 0
Polarity : 1
Always On : 0
[050h 0080 8] Counter Read Block Address : FFFFFFFFFFFFFFFF
...Most AArch64 SoC systems have one or more GIC-compatible interrupt controllers. Windows has inbox GIC support, all needed is supplying proper information in the MADT table. The table also describes ARM Performance Monitor Unit information for system’s reference. In device tree, GIC and PMU look like this:
gic: interrupt-controller@50041000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
interrupt-controller;
reg = <0x0 0x50041000 0x0 0x1000>,
<0x0 0x50042000 0x0 0x2000>,
<0x0 0x50044000 0x0 0x2000>,
<0x0 0x50046000 0x0 0x2000>;
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
interrupt-parent = <&gic>;
};arm_pmu: arm-pmu {
compatible = "arm,armv8-pmuv3";
interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>;
};An example of the MADT table can be found here.
Microsoft defines DBG2 table for ARM platforms. Although Microsoft docs mark DBG2 table info as mandatory, you do not need to supply debug device information if you just want to boot Windows as a proof-of-concept :P. An empty DBG2 table is enough for booting.
For debug purposes, it is necessary to define at least one debug device (8250/16550 serial or USB) in DSDT and DBG2 table. More information can be found at here.
Indicates PSCI support and Hardware-reduced ACPI mode, then you are good to go.
It’s incredibly difficult to debug early ACPI startup if you don’t have serial or debug access on the platform. Fortunately, Linux provides some utility for it. It is feasible to enable the UEFI FrameBuffer early printk support on 5.0+ kernels to simplify the debug process.
With much effort, Windows on ARM can run on a variety of AArch64 devices. There’s still much work between “just-booted” and “usable”, and it may cost you countless nights to achieve your marvel, even if there are always guys ask you “why”:
Sometimes it is not feasible to get UART access on consumer blackbox devices (e.g. Lumia 950XL). In the case of ARM ACPI debugging, the lack of UART access may make early boot debug incredibly difficult.
Starting from Linux Kernel 5.0, it is now possible to enable FrameBuffer-based early kernel display. All you need to do is:
Then pass the following parameters in bootloader:
earlycon=efifb,memThen you are good to go.
A colleague told me a Windows Server 2016 node entered an inconsistent state after an abnormal shutdown. The following symptoms were observed:
A quick diagnostics indicated a component failure with Windows Management Instrumentation. To determine the failure source, I ran WMIDiag from Microsoft. The log showed a metadata failure:
.1526 21:47:43 (1) !! ERROR: WMI CONNECTION errors occured for the following namespaces: ………………………………………….. 20 ERROR(S)!
.1527 21:47:43 (0) ** - Root, 0x80010114 - The requested object does not exist..
.1528 21:47:43 (0) ** - Root, 0x80010114 - The requested object does not exist..
.1529 21:47:43 (0) ** - Root/subscription, 0x80010114 - The requested object does not exist..
.1530 21:47:43 (0) ** - Root/DEFAULT, 0x80010114 - The requested object does not exist..
.1531 21:47:43 (0) ** - Root/CIMV2, 0x80010114 - The requested object does not exist..
.1532 21:47:43 (0) ** - Root/CIMV2/Security, 0x80010114 - The requested object does not exist..
.1533 21:47:43 (0) ** - Root/CIMV2/TerminalServices, 0x80010114 - The requested object does not exist..
.1534 21:47:43 (0) ** - Root/nap, 0x80010114 - The requested object does not exist..
.1535 21:47:43 (0) ** - Root/SECURITY, 0x80010114 - The requested object does not exist..
.1536 21:47:43 (0) ** - Root/STANDARDCIMV2, 0x80010114 - The requested object does not exist..
.1537 21:47:43 (0) ** - Root/RSOP, 0x80010114 - The requested object does not exist..
.1538 21:47:43 (0) ** - Root/RSOP/User, 0x80010114 - The requested object does not exist..
.1539 21:47:43 (0) ** - Root/RSOP/Computer, 0x80010114 - The requested object does not exist..
.1540 21:47:43 (0) ** - Root/WMI, 0x80010114 - The requested object does not exist..
.1541 21:47:43 (0) ** - Root/directory, 0x80010114 - The requested object does not exist..
.1542 21:47:43 (0) ** - Root/directory/LDAP, 0x80010114 - The requested object does not exist..
.1543 21:47:43 (0) ** - Root/Policy, 0x80010114 - The requested object does not exist..
.1544 21:47:43 (0) ** - Root/Microsoft, 0x80010114 - The requested object does not exist..
.1545 21:47:43 (0) ** - Root/Microsoft/HomeNet, 0x80010114 - The requested object does not exist..
.1546 21:47:43 (0) ** - Root/aspnet, 0x80010114 - The requested object does not exist..The documentation suggested performing a metadata registration. The following script is utilized for the metadata repair:
@echo on
cd /d c:\temp
if not exist %windir%\system32\wbem goto TryInstall
cd /d %windir%\system32\wbem
net stop winmgmt
winmgmt /kill
if exist Rep_bak rd Rep_bak /s /q
rename Repository Rep_bak
for %%i in (*.dll) do RegSvr32 -s %%i
for %%i in (*.exe) do call :FixSrv %%i
for %%i in (*.mof,*.mfl) do Mofcomp %%i
net start winmgmt
goto End
:FixSrv
if /I (%1) == (wbemcntl.exe) goto SkipSrv
if /I (%1) == (wbemtest.exe) goto SkipSrv
if /I (%1) == (mofcomp.exe) goto SkipSrv
%1 /RegServer
:SkipSrv
goto End
:TryInstall
if not exist wmicore.exe goto End
wmicore /s
net start winmgmt
:EndIt will throw some errors. Ignore them. Then reboot the server.
It’s almost a year for Lumia950XLPkg and its derivative projects. A new touch-enabled graphical menu will be added in coming weeks (I’ve posted a picture on Twitter).
There are a few more things to do (mostly bugfix) after the PCIe initialization (Talkman variant will be released later). Here’s a list of current backlog:
This UEFI project will be finalized on March or April, then I will transfer the ownership to LumiaWoA organization.
Lumia950XLPkg makes it possible to run mainline Linux on Lumia 950 XL. So far I’ve brought up main components including touchscreen and Bluetooth. Wi-Fi will be available once I figure out the way to declare firmware-initialized PCIe bus in device tree.
Freedreno is also possible. However, it may takes significant time to figure out proper MIPI DSI commands for display panel enablement.
There are other people working on Android-side project for Lumia 950 XL, but I am unable to disclosure the progress at this moment.
I am excited to announce that I am joining Microsoft / LinkedIn in the coming summer. But the employment may have potential CoI (conflict of Interest) on projects that I am currently working on. I wish I can continue on making the next big thing 😛
I got a Nintendo Switch from my friend (for a research project). Meanwhile, I enjoyed the game “Overcooked” on Switch. In this game, you control cooks to perform variety tasks and then deliver orders in time. If orders are delivered in advance, some tip will be given. 1-4 players can play the game simultaneously.
It’s clear that you have to do everything as quick as possible to achieve high score in the game. Every task (e.g. cutting meat) need some time to complete. Certain task (e.g. frying) depends on other tasks. To eliminate unnecessary time cost (i.e. waiting for cutting to complete), I use the following strategies:
Not all kitchens are easy to deal with. Some have dynamic arrangements – contents may change their location during the game session. Some kitchens have no constant light source. Other have isolated workspaces with conveyor belts or tables for swapping materials (I call it a “bus”).
Get familiar with your kitchen and good luck! (Well, it is a bit boring if you have learned Machine Architecture and Operating System internals).
Nights before trips are always boring, and I decided to draft some words to spend the time. So we have Windows 10 on ARM running on Dragonboard 410c, and Lumia 950 XL (Article in Chinese, sorry). It will be helpful to write down some firmware-related information for platform bring-ups for further reference. Meanwhile, the comparison of Little Kernel, the common Linux Android (well, Qualcomm says so) bootloader will provide useful information for Android on Lumia project.
I recommended you read this article if you are not familiar with UEFI.
Compared to Linux, Windows Kernel assumes its platform firmware and bootloader (aka. Windows Boot Manager) prepare the basic environment for successful kernel initializations. If certain components are not initialized, bugchecks may occur. Even the system successfully launches, it may have some unexpected behaviors (weird things). An official document explains these a lot.
Little Kernel initializes basic hardware too (at least you need serial for debugging). Certain periapical, including clocks, regulators, and USB are initialized too for application purposes (e.g. Fastboot). Anyway, it initializes less periapical as possible. Sometimes even the panel is not brought up (I’ve seen a case on Android phone).
In short, you have to do more for a successful Windows bring-up:
So how about Linux? If your Linux platform uses DT instead of ACPI, you are likely not required to do most of the stuff Windows requires. On Qualcomm platforms, Linux kernel will clock up PCIe cores, set regulators and mappings to make it in the usable state. If your platform uses standard ACPI and platform drivers do not perform additional initialization procedures, initialize these components in firmware.
Both UEFI w/ ACPI and LK will perform fix-up tasks before transferring control to the kernel. On Qualcomm platforms, chipset metadata (revision, foundry ID, etc.) will be filled in DSDT. Certain logic in DSDT depends on them. Typical Linux Android device will ship with a large DT for multiple variants. LK selects the best fit using chipset ID/PMIC ID/board ID, then fill in some memory region information for kernel use.
ACPI tables in the firmware for Windows 10 on ARM is pre-patched. So I don’t implement the fix-up logic additionally.
Why am I discussing the thing again? Because it is important.
Little Kernel (and likely other Linux Android bootloaders) will only use a single processor in its lifecycle (a notable exception is Raspberry Pi, which uses spin table except 3+). When it transfers control to Linux, Linux will bring other cores out of reset state and make them available for use.
Windows platforms that implement ACPI Multi-Processor Parking Protocol behaves differently. Although firmware uses a single core, other CPU cores are brought out of the reset state and being instructed to run a special piece of code. The code flow is like this:
parking:
Wait for an interrupt.
Am I the processor being waked up?
If yes, go to the address that OS told me
If not, go back to parking.
(Interrupt acknowledgment and memory barriers ignored. Sorry, I don’t want to write assembly at 11 PM.)
Because different platforms handle core startup differently (on Qualcomm platforms, TrustZone has participated), booting Linux Kernel and starts cores the Linux way with a UEFI firmware that implements this protocol may fail. Someone told me he was unable to bring up other three cores on 640. It is reasonable since LK on recent Lumia phones is launched via a special UEFI application in Windows Boot Application form. Qualcomm UEFI put the other three cores in running state (and WFI). Both LK and Linux are not aware of that (they have the assumption of core state). Finally, core startup fails.
Since it is not possible to ditch Qualcomm UEFI (unlike the exploit for first-generation Lumia WP8 devices), we have to comfort the parking protocol in AArch32 mode (You have PSCI for AArch64 SoCs):
Good night (And to my girlfriend: If you see this article, sorry that I say “Good Night” too early.)
Also posted here: Bringing up Windows 10 AArch64 on a $50 Single Board Computer
Windows on ARM is not a new topic. There are some guys attempted to bring up Windows RT and Windows 10 on Qemu (ARM/AArch64 target). It even runs on Raspberry Pi 3. Obviously it is not a Snapdragon 835-only thing. We can give it a hand on our own Single Board Computers.
This article covers some important details in Dragonboard 410c SBC’s aa64 UEFI implementation.
These requirements are fairly similar to ARM SBBR certification requirements. If your SBC has a working EDK2/TianoCore UEFI, then you are probably good to go. Bootstrapping your own EDK2 is pretty easy too.
The board I used (DragonBoard 410c) doesn’t have a known EDK2/TianoCore implementation. So I have to build my own. This repository for Raspberry Pi 3 is a good start point and reference for you.
You need to do these things in UEFI:
Memory allocation is a platform-specific thing. Check your platform HRD to get some idea about MMU and memory allocation. For Snapdragon 410, check out Qualcomm LM80-P0436-13.
Our UEFI FD starts at 0x80200000. Update your tokens in platform definition and flash definition:
And the first piece code should be your SEC initialization code (without relocation).
Little Kernel (mentioned below) will be responsible for jumping into UEFI FD at 0x80200000 and handing off execution. If you want, you can actually removes Android-specific header and device tree validation in LK (apps/aboot.c).
DragonBoard 410c uses ARM Secure Monitor Call to switch to AArch64 mode (See Qualcomm LM80-P0436-1 for more information). The stock close-sourced SBL doesn not recognize AArch64 ELF files (later model should). LK performs basic platform initialization (UART, eMMC, MMU, etc.) A modified variant LK also initializes FrameBuffer for U-Boot. We can make it work for our UEFI too.
Windows requires UEFI provide a BGRA FrameBuffer. To achieve this, we need to modify pixel unpack pattern in platform/msm_shared/mdp5.c:
case 32:
/* Windows requires a BGRA FB */
writel(0x000236FF, pipe_base + PIPE_SSPP_SRC_FORMAT);
writel(0x03020001, pipe_base + PIPE_SSPP_SRC_UNPACK_PATTERN);
You can either specify a hard-coded address for FrameBuffer, or have a random piece of memory block to transfer information (pixel format, width, height, etc.) to UEFI. UEFI SEC phase retrieve the information, allocate HOB block and transfer information to DXE phase. A simple FrameBuffer driver retrieve information from HOB block, initializes UEFI Graphics Output Protocol. For optimal performance, initialize this piece of memory block as write-through cache memory in MMU initialization.
For persistent NVRAM support, it’s a good idea to use eMMC as storage device. This implementation demonstrates how to simulate NVRAM using eMMC and a piece of memory. I slightly modified it make it work for Qualcomm devices:
Windows Boot Manager depends on a “working” Real Time Clock for miscellaneous purposes. APQ8016/MSM8916 has a RTC on its PMIC processor PM8916. To access RTC services, read/write SPMI registers (see Qualcomm LM80-P0436-36). If you are lazy, just use Xen fake RTC in ArmVirtPkg.
To enable PM8916 RTC, set SPMI register 0x6046 to enabled state, then read 0x6048 and three following bits.
Note: I implemented my own PMIC protocol called PM8916Protocol that read/writes PMIC register on SPMI bus, slave #0. This RTC library is based on Xen face RTC library from ArmVirtPkg.
Revised: On certain SoC platforms, runtime memory allocations are not comply with 64KB alignment requirements. There are two solutions, either round these memory regions to 64KB alignments, or go to MdePkg/Include/AArch64/ProcessorBind.h:
///
/// The stack alignment required for AARCH64
///
#define CPU_STACK_ALIGNMENT 16
///
/// Page allocation granularity for AARCH64
///
#define DEFAULT_PAGE_ALLOCATION_GRANULARITY (0x1000)
///
/// For the sake of our SBCs
///
#define RUNTIME_PAGE_ALLOCATION_GRANULARITY (0x1000)
I randomly hit crashes (synchronous exception) during my UEFI development. After some investigation, it seems that the problem is related to load/store commands. (See ARM Errata 835769, 843419) To prevent random crashes, add these two flags to your GCC compiler:
For platforms that implement ARM PSCI, indicate PSCI support in ACPI FADT table:
EFI_ACPI_6_0_HW_REDUCED_ACPI | EFI_ACPI_6_0_LOW_POWER_S0_IDLE_CAPABLE, // UINT32 Flags
{
EFI_ACPI_6_0_EMBEDDED_CONTROLLER,
0,
0,
EFI_ACPI_6_0_DWORD,
0x009020B4
}, // EFI_ACPI_6_0_GENERIC_ADDRESS_STRUCTURE ResetReg
1, // UINT8 ResetValue
EFI_ACPI_6_0_ARM_PSCI_COMPLIANT, // UINT16 ArmBootArchFlags
EFI_ACPI_6_0_FIXED_ACPI_DESCRIPTION_TABLE_MINOR_REVISION, // UINT8 MinorRevision
Typically you don’t need HVC call for PSCI. If you did so (and your platform doesn’t support HVC call for PSCI), you will get a INTERNAL_POWER_ERROR bugcheck with first parameter of 0x0000BEEF.
If you indicates PSCI support, you don’t have to provide parking protocol version in your ACPI MADT table. Simply set it to 0. Here’s one example:
[02Ch 0044 1] Subtable Type : 0B [Generic Interrupt Controller]
[02Dh 0045 1] Length : 50
[02Eh 0046 2] Reserved : 0000
[030h 0048 4] CPU Interface Number : 00000000
[034h 0052 4] Processor UID : 00000000
[038h 0056 4] Flags (decoded below) : 00000001
Processor Enabled : 1
Performance Interrupt Trigger Mode : 0
Virtual GIC Interrupt Trigger Mode : 0
[03Ch 0060 4] Parking Protocol Version : 00000000
[040h 0064 4] Performance Interrupt : 00000017
[044h 0068 8] Parked Address : 0000000080301000
[04Ch 0076 8] Base Address : 0000000000000000
[054h 0084 8] Virtual GIC Base Address : 0000000000000000
[05Ch 0092 8] Hypervisor GIC Base Address : 0000000000000000
[064h 0100 4] Virtual GIC Interrupt : 00000000
[068h 0104 8] Redistributor Base Address : 0000000000000000
[070h 0112 8] ARM MPIDR : 0000000000000000
[078h 0120 1] Efficiency Class : 00
[079h 0121 3] Reserved : 000000
See ARM Juno reference platform to get some idea about crafting ACPI tables.
Spend some nights writing Windows drivers. 😛
Windows 10 PE runs on a Spandragon 410 processor.