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).
UEFI: Finalized
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:
Touch-enabled menu for boot device selection and basic settings
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.
Debian on Lumia 950 XL demonstrating Bluetooth HCI status
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.
Joining Microsoft / LinkedIn
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:
Minimize workers’ stall time (doing nothing). For example, it is not necessary for workers to wait for frying process (polling is not efficient). Like interrupts in modern machines, they can do something else like washing dishes and cutting meats while waiting for cooking. Once interrupt signals (frying completes), they enter interrupt servicing routine: get the food put into a plate. In most cases, the food is ready to serve then. Finally, they returned to what they were doing.
Again, make sure everything is doing something. This is especially important if you are playing with your friends. You had better analyze the dependency chain and discuss strategies with your friend before starting the game. Of course you should issue instructions to your friend during game if necessary.
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”).
Tables for swapping are usually space-constrained. If you are playing with your friends, you are probably simulating a Symmetric Multiprocessing system, and the bottleneck will be bus bandwidth. In such cases, you should consider the priority of materials. Once transfer finishes, get them as soon as possible.
Conveyor belts are high-latency bus, but they have relatively high bandwidth (Hey DDR4, I am looking at you). In some kitchen scenarios (e.g. making burgers), you can put everything on the belt in batches and fetch in batches too.
Some conveyor belts connect to trash can, which means materials must be fetched before the expiration. But some cook utilities will appear again if you put them into the trash can. In this way, you can prioritize the transfer of contents on the conveyor belt.
Try achieve full-duplex transfer and prefetch to save time. Consider the following scenario: you have a pot that cooks rice at once side, and food materials (rice and flour tortilla) on the other side. For the first time, you get rice and put them into pot. Once rice finishes, you carry cooked rice to the other side and wrap them with tortilla. Don’t get tortilla separately in another transfer. If you really have to do that, you can instruct other cooks (if exist) to prefetch some for you.
Prefetch might not work for all kitchens. In the case of cooking soup, mice will steal your food if it is unattended for a while. But you can secure processed food in pots so it won’t get stolen.
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.
Assumptions, assumptions
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:
If you know certain components are in the usable state already, skip initialization procedures. For example, on Lumia 950 XL, our UEFI implementation does not need to initialize USB since our bootstrapper (Qualcomm UEFI) did so.
If your platform has PCIe components, clocks them up, set regulators and mappings, etc.
Initialize at least one debug resource described in your DBG2 table (if applicable, likely on all ARM platforms)
Bring up the panel, set basic display parameters and pass a framebuffer pointer for Windows.
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.
Fill the hole
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.
Multi-processor Startup, Again
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):
Ignore other cores Unicore is the best
Implement parking protocol for unsupported systems (not too hard). Linux has the protocol support; you have to enable it.
Go AArch64 and use PSCI (remember to use HVC mode for 8992/8994)
Good night (And to my girlfriend: If you see this article, sorry that I say “Good Night” too early.)
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.
Contents
Windows Boot Requirements
Bootstrapping your own EDK2/TianoCore UEFI
Memory Allocation / Memory Management Unit
UEFI Flash Definition
First-stage Bootloader (Little Kernel)
Persistent NVRAM Support
A “Working” RTC
Multi-processor startup (PSCI)
Windows Boot Requirements (AArch64)
AArch64 architecture processor. It seems that AArch64 cryptography extension is required too (Raspberry Pi 3 randomly throws UNSUPPORTED_PROCESSOR bugcheck, rs4 fixed the issue). The bugcheck is raised in Errata Check (a hardcoded ID check).
A working interrupt controller. Most AArch64 SoC cores include ARM GIC, so there’s little work to do here. The only exception I know is BCM2837. Windows has inbox Broadcom interrupt controller support (for the sake of Raspberry Pi). But if your SoC has additional third party interrupt controller, you need to supply your own HAL extension library. There is few documentation for this available though…
A working processor timer. If not, supply your own HAL extension library.
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.
Bootstrapping your own EDK2/TianoCore
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:
Initialize serial output (for debugging) and Memory Management Unit (MMU). Refer to your platform datasheet for device memory address allocation.
Retrieve required information from pre-UEFI environment and build Hand-off Blocks (HOB) for DXE phase
Initialize processor (exception vector, etc.) in DXE phase.
Initialize UEFI services (variable services) in DXE phase.
Jump to BDS phase, start Windows Boot Manager or something else.
Memory Allocation / Memory Management Unit
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.
UEFI Flash Definition
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).
First-stage bootloader (Little Kernel)
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.
Persistent NVRAM Support
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:
If eMMC NVRAM region is corrupted or uninitialized, provision it and perform a platform warm reset so I don’t get a synchronous exception in volatile variable initialization phase.
Modify dependency relationship to prevent “device not found” error in BlockRamVariable DXE initialization.
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.
4KB / 64KB Page Table
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
///
/// For the sake of our SBCs
///
#define RUNTIME_PAGE_ALLOCATION_GRANULARITY (0x1000)
ARM Erratum
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:
Multi-Processor Startup (PSCI)
For platforms that implement ARM PSCI, indicate PSCI support in ACPI FADT table:
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:
Windows 8 and Windows 8.1 has a minimum screen resolution constraint for Windows Store Apps (aka. Metro Apps or whatever). If the screen resolution doesn’t meet requirement, user will see a prompt indicating the resolution is too low for these applications.
However, on certain platforms (like phones and single-board computers), it is not convenient to change resolution. Recently I am trying Windows RT 8.1 on Lumia 640 XL. Qualcomm has the resolution hard-coded in platform configuration, so I was unable to change the resolution. 1280 * 720 is not sufficient for Store Apps.
But there was an exception – the PC settings (aka. Immersive Control Panel) app. It always opens regardless of current resolution settings. So how can I force other applications to launch?
Let’s turn to TwinUI.dll. It’s one of the core components of shell infrastructure. Start IDA Pro, load TwinUI with symbols from Microsoft. Go ahead and search the existence of PC settings app. All Windows Store Apps are associated with a package family identifier. Let’s search it. In this case, it’s windows.immersivecontrolpanel_cw5n1h2txyewy.
Bingo. We found it in some functions.
PC Settings Package Family ID is hardcoded in TwinUI.dll. This function has been patched by me, so it doesn’t reflect actual situation you get from official Microsoft binary.
By checking it’s references, we learned that layout checking routine verifies whether it is a desktop application, or PC settings app when resolution doesn’t meet requirements. Either you can patch layout checking routine or PC settings PFN verification routine. I decided to patch the second one, however patching the first is probably a better idea.
On ARMv7-A platform, I simply patched initial register store operation and the branch. Instruction BLX call was replaced with a simple NOP(MOV R0, R0).
Patched function
There are two version of the PC settings check routines, so I need to patch both. The other one is similar to this one. Patching the layout verification routine (actually a better idea, as this patch will have some trouble when launch files from desktop) / patching on other architectures should be similar to this one.
Two days ago I set up a new virtual machine for applications that require isolated security. When I put my computer into Connected Standby mode, I noticed SoC fan didn’t stop. To verify whether it was OS inconsistency or persistent issue, I manually initiated a system restart. However, it froze at login screen then. Nothing responded, including Ctrl + Alt + Delete key sequence. Attempting to force shutdown and start the computer almost didn’t improve the situation. After about ten attempts I managed to enter my desktop. There was no clue in event viewer: everything went well then suddenly the system froze.
I remembered that an alternative OS loader entry was configured to bypass Hypervisor launch at startup. I selected this entry to see whether it was related to Hyper-V. Test results indicated the freeze issue was strongly related to Hyper-V.
I tried to remember what I did before virtual machine configuration. I removed a virtual switch bridged to Surface Ethernet Adapter on my Surface Dock, then added a virtual switch bridged to VMware NAT adapter (which works better with Wireless network). Then I checked adapters in Network and Sharing Center, the old virtual switch didn’t get removed at all – and the “Remove” menu entry was unavailable. At last, I removed this adapter from Device Manager, and the issue was resolved.
This issue is likely related to OS inconsistency. When Hyper-V infrastructure attempts to initialize (bring up) all enabled network adapters including these Hyper-V virtual switches, the “removed” adapter is brought up, then enters failure state due to inconsistency in configuration. Because host operating system is a virtual machine on Hyper-V (with privileges), the host OS didn’t even get a chance to record what happened at that point.
The good thing is that I fixed it by myself; The bad thing is I missed an opportunity to report this bug and let Microsoft fix it.
When Microsoft decided to adopt MSBuild on .NET Core platform, project.json was not dropped immediately until first toolchain RTM arrives. Dotnet Development on Universal Windows Platform Development leverages .NET Core too, but the depreciation progress is significantly slower than other .NET Core platforms due to historical reasons. UWP uses project.json for package management and MSBuild for builds.
In Visual Studio 2017 April Update, Microsoft finally migrates new UWP projects to full MSBuild-based project system. But our projects, which creates on early 2015, doesn’t get an auto migration as expected. Hence we decided to migrate them manually for additional benefits like better toolchain stability and advanced customization features.
Reminder: Do not attempt to use “dotnet migrate” CLI command, it won’t work for UWP projects.
Migration Prerequisites
Notify all your team members. Make sure everyone has Visual Studio 2017 with April update installed.
If you have continuous integration environment configured, make sure build agents have NuGet 4.1 or higher installed (3.5 or 4.0 won’t work).
Lock VCS during migration to prevent additional incidents. (We’re using TFVC for source management so that it will be easy)
Migration
Clean up all projects (including bin and obj directories)
Iterate all project directories
Find C# project file, open with your favorite editor.
Add following property group before project file lists:
<PropertyGroup>
   <RestoreProjectStyle>PackageReference</RestoreProjectStyle>
</PropertyGroup>
Okay, you’ve completed the first step. Then open your project.json file. Migrate all NuGet packages references as the picture below.
Package Reference
Finally, remove project.json and additional files like project.lock.json, *.nuget.targets, *.nuget.props. (Or your will get lots of warning that may lead .NET Native compilation fail)
Do it for every project. Then open Visual Studio, restore NuGet packages for all projects, build to validate and submit changes.
First of all, Windows “Gatekeeper” doesn’t block the execution of applications that don’t require installation. I tried to run PuTTY, a popular tool on Windows and it works.
Secondly, Windows “Gatekeeper” is based on Microsoft SmartScreen, which means disabling SmartScreen will turn it off too. Prior to application execution, SmartScreen will send file hash and publisher information(including certificate thumbprint) to Microsoft’s server, then SmartScreen server send back metadata including application reputation. Response is signed with a specific key that will be checked in client side for message integrity.
Unlike macOS, attempt to start application from console(e.g. Command Prompt and PowerShell) will trigger “Gatekeeper”.
Attempt to start application from PowerShell
The window is web-based. Although you can’t modify the response directly(no one wants to deal with sha256RSA unless the key leaks), you can attach a debugger to have some fun with it.
“Rickrolling” in Windows SmartScreen
Microsoft claims that this feature is opt-in for most Windows SKUs (except Windows 10 Cloud AFAIK), and it is not revalent to UMCI (User-mode Code Integrity), which is enforced in Windows 10 Cloud.
Windows 10 PE runs on a Spandragon 410 processor.
PC Settings Package Family ID is hardcoded in TwinUI.dll. This function has been patched by me, so it doesn’t reflect actual situation you get from official Microsoft binary.
Patched function
Attempt to start application from PowerShell
“Rickrolling” in Windows SmartScreen