The MEGA Windows on Arm thread

[diydavindra]

So i've gotten pretty close to getting windows 10 arm to boot. But for some reason after selecting the boot device it wont no longer detect the keyboard, when the press any key to continue prompt arrives. The numlock light will turn on but no matter what button i press nothing happens. Also since it doesnt detect a keyboard input it will go back to the last screen and the system seems to lock up at that point.

[diydavindra]

I've also tried two different keyboards both seem to not have an effect.

[andreiw]

Do me a favor and repeat your experiment with the input being done over the serial input instead of USB. I bet you’ll discover similar behavior.

Actually, please send me a serial log of your experiments produced by a debug build of the UEFI firmware. That should help immensly.

I’ve seen something similar with winload.efi - it draws the pretty “uh-oh” blue screen, but the keys to reboot or exit to firmware don’t work - almost as if the code is waiting for a debugger or if interrupts are disabled. With a debug edk2 build I saw periodic UEFI messages stop printing as well.

[thchi12]

You can try applying the wim file manually,make two partitions on your sdcard or USB,one FAT and one NTFS,then use dism to apply the image and bcdboot to create boot files.

[thchi12]

AFAIK,using the latest firmware Windows still hang at the boot screen,there seems no sign of loading and no 0xc0000225

[diydavindra]

Sadly i don't have a serial cable to hook up to the pi, tho im not too sure how to communicate with it that way my guess is a serial to usb and putty on my pc. I've seen people posting images of the 0xc0000225 blue screen and i have no idea how they are even getting that far.

[thchi12]

Juat as I said,apply the install.wim manually

[andreiw]

Folks, I've updated the readme.md file with the steps required to build arm64 WinPE USB media. You should be able to follow them provided you have a Windows 10 machine (any will do, x86, amd64 or arm64).

Also, see https://github.com/andreiw/RaspberryPiPkg/tree/master/Binary/prebuilt/2018Apr21-GCC49, which should make it more obvious what is happening. See screenshot. You should be able to repeat my "success" (for lack of a better term, given that we're crashing somewhere in NT after UEFI exits).

Since the current version (Apr 21st) and latest WoA WinPE bits seem to act much more reasonably than this ticket implies, I'm closing it as resolved.

[andreiw]

Guys, take a look at https://github.com/andreiw/RaspberryPiPkg/tree/master/Binary/prebuilt/2018Apr22-GCC49 and the latest notes in readme.md. Everything you need to repeat is in there.

I can get WinPE booting. If it wasn't for https://twitter.com/ntauthority 's helpful hint, wouldn't be anywhere close.

[andreiw]

I'll see if I can make any progress on SMP.

It would be nice to figure out where the MCCI (https://twitter.com/NTAuthority/status/957886027594641409) USB driver for DWC_OTC can be found.

The rest of the RPi3 drivers are open source and could be hypothetically build with the EWDK (https://github.com/ms-iot/bsp/tree/master/drivers) - untried, but it seems like @NTAuthority built some.

[diydavindra]

Wow you guys got pretty far, I'm gonna try this in a bit and see what happens.

[thchi12]

wow That's amazing! Is it possible to use PSCI to get SMP?WOA needs either mppp or psci to get multicore. According to https://zhuanlan.zhihu.com/p/34572676 Windows has built in support for BCM interrupts,and what's the problem that prevents windows from starting up?

[andreiw]

This firmware already exposes PSCI support (go boot Linux and see ;-)), but the ACPI tables are as-is from MS-IoT and thus still report MPPP and no PSCI in FADT.

[thchi12]

In the earlier versions there were acpi tables for psci ,I wonder whether adding only dsdt ,csrt,dbg2 could help or not.

[andreiw]

@thchi12, nope, unrelated.

[andreiw]

As far as RPi3 support there appears to be a check in Hal validating PIC is not a BCM PIC. That’s why you need a debugger attached to patch out the ‘bls’ following the subtraction and compare.

[diydavindra]

Would it be possible to use the usb driver from the windows IoT? Cause im trying to get my hands on the file for it.

[thchi12]

I don't think arm32 drivers can be used on arm64@daveb778

[diydavindra]

@thchi12 Good point i didnt think that through.

[andreiw]

You need a 64-bit driver. IoT core is 32-bit. Hypothetically, if I understood @NTAuthority correctly, the driver might have shipped as part of the NT-based 64-bit Wndows Mobile. I don’t know much about the later, in terms of which version first had AArch64 support (8.1 or 10...).

[diydavindra]

@andreiw I see, i guess the does beg the question how do we get hold of it.

[thchi12]

It seems that rx-130 phones may have win10m arm64

[diydavindra]

Oh, also trying to make the pe disk but i keep running into errors. https://puu.sh/A8iYa/2f307aa6a4.png

[thchi12]

Well you can try to grab uup and make an installtion media,keeping only the efi and boot.wim under sources

[diydavindra]

Nvm just tried a smaller sdcard that did the trick.

[thchi12]

http://tieba.baidu.com/p/5650553455?share=9105&fr=share&see_lz=0&sfc=copy&client_type=2&client_version=9.4.8.4&st=1524405579&unique=17AB6B5F22E960726FBC25BC1894B03E Here's my only known win10m aarch64 .(Don't worry as English translation is done below.I don't know whether it helps or not

[diydavindra]

I dont know if we can even get the drivers from the backup. Also i just placed an order for a serial adapter so that should be a big help.

[andreiw]

Yeah you pretty much need the serial adapter today to have that windbg connection, until I figure out how to hot-patch the Hal... That’s probably where most of my current interest around WoA, after I resolve the PSCI issue. So if someone wants to focus on locating and validating the USB controller driver (https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/add-and-remove-drivers-to-an-offline-windows-image), that would be fantastic.

[andreiw]

@daveb778 until I add high-speed support to the SD host controller UEFI driver, I recommend you use USB keys for your OSes (Linux, FreeBSD, WoA), unless you really like waiting. USB is much faster. Your SD card should pretty much just contain UEFI.

[diydavindra]

@andreiw Ahh kk, i've been mostly doing just this. But yea im basically stuck waiting for a serial adapter from amazon for now. Also im not too sure how to track down the usb driver, ive been looking with no luck so far.

[nta]

The original USB driver was built for ARM32 only and therefore wouldn't work on ARMv8 Windows, I should probably open-source my hacky attempt at an UCX-based USB driver since I've not had time to work on it for a while now.

Windows Phone devices used a Synopsys DesignWare USB controller as well, however this was the USB3 variant, which is pretty much distinct from the USB2 one used by Broadcom.

Also, yeah, I've noticed that the current SD UEFI driver is slow when booting Windows from the SD card, other than that, wonderful work on the project in general, @andreiw. 🙂

[nta]

OK, I pushed the local working state of my USB driver to nta/dwusb.

As to patching the HAL at runtime, it should be noted that winload.efi will check both the PE checksum as well as a digital signature at load-time, so if intercepting FS requests, this file should be patched as well. It does appear such checks aren't made if boot debugging is enabled, however, but that'd not get rid of the need for a live serial connection.

[andreiw]

@nta - wow, I feel your pain...having spent a few months off-and-on rewriting the crappy UEFI DwUsbHostDxe driver I found. Kudos for diving in and writing your own! My UEFI driver is wrong in principle (I still have no idea how this hardware is supposed to do periodic transfers), and CBI devices are still a mystery to me. It's frustrating that there are still no reasonable docs on the chip (the best I could find is https://www.quicklogic.com/assets/pdf/data-sheets/QL-Hi-Speed-USB-2.0-OTG-Controller-Data-Sheet.pdf). Maybe I should have just taken the BSD one as a base...

As far as patching the HAL I've been sort of eyeing dreamboot (https://github.com/quarkslab/dreamboot) and UEFI-Bootkit (https://github.com/dude719/UEFI-Bootkit).

Idea 1: boot WoA in EL1. Use a passthru "hypervisor" and stage 2 mappings to ensure patched EL1 VPN are either executable and not readable (then they contain patched code) or readable and XN (when code tries measuring itself we can feed it the original copy). This avoids the need to figure out how to disable patch guard.

Idea 2: rely on an EL3 agent in ATF (via an SMC) to manipulate VAs. Still have to disable patch guard, but because EL3 can use AT to translate EL1 VPNs to MPNs and access directly, we don't need to worry about non-writable mappings.

Of course, maybe some kind soul in Microsoft could just fix the check ;-D?

[andreiw]

So the good news is that I have PSCI working in WoA, with all 4 cores online.

The bad news is that I have a crash. Lack of checked kernel is making this hard (I didn't find checked kernel/hal in either the 17125 EWDK or 17125 WDK), so the names of the functions in the call stack don't mean anything - they were just the closest symbol ;-(.

Bug check is 0x6b (PROCESS1_INITIALIZATION_FAILED). https://neosmart.net/wiki/0x0000006b/ implies this has something to do with ntdll.dll.

BUGCHECK_P1: ffffffffc0000605 (NTSTATUS??? -> STATUS_IMAGE_CERT_EXPIRED???) BUGCHECK_P2: 3 BUGCHECK_P3: 0 BUGCHECK_P4: 0

I don't really understand what booting with more than 1 CPU has to do with it, though... And this is a WinPE system where everything is in RAM. Really - if I set the "Processor Enabled" flag to 0 for the other 3 GIC entries in Madt.aslc, the system boots. The must be some state between the the BSP and APs that is not identical, but I haven't yet sorted out what that could be. ATF handles all the dirty work of EL3 initialization (and it was good enough for Linux), and even the timer is configured as expected (19.2Mhz).

[thchi12]

Maybe there's still something needed to do with the bcm interrupt?

[andreiw]

Hmm, actually the TARGET_TIME is conspicuous. RPi3 has no RTC, so it is being faked out.

The OSBUILD_TIMESTAMP is 2018-03-15 21:28:59.

In a "good" boot TARGET_TIME was 2018-03-16T01:35:12. In the 0x6b case, the TARGET_TIME is 2052-04-16T16:31:52. That does explain the cert failure...

[thchi12]

Hmmm... How about 17128+?Fetching uup files then converting into an iso and get the boot.wim. 17128+ has no timebomb

[nta]

Timebombs aren't related to these code integrity checks.

On Mon, Apr 23, 2018 at 9:57 AM thchi12 notifications@github.com wrote:

Hmmm... How about 17128+?Fetching uup files then converting into an iso and get the boot.wim. 17128+ has no timebomb

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/andreiw/RaspberryPiPkg/issues/12#issuecomment-383487569, or mute the thread https://github.com/notifications/unsubscribe-auth/AD0WZSBKmfUPe53Wfyf8hZLcTv5bt1TBks5trYl5gaJpZM4TeRmG .

[diydavindra]

Oh wow that time difference, Would it be possible to add a RTC to the pi or just emulating one would probably be easier. After a some googling i did find that there is addon boards that can add a RTC tho im not sure of the possibility on how it would talk to the UEFI or WoA https://www.adafruit.com/product/3386

[thchi12]

BTW I'm wondering how the time goes to 2052,I tried 14282 before this thread opened and it didn't show me the digital siganature problem.And the bomb for it should before 2016

[thchi12]

Before 2016 July

[andreiw]

I’ve spent a few hours “fixing” the UEFI RT RTC implementation, before realizing it’s not actually used by the Hal. HalpQueryAcpiRealTimeClock returns 0xc0000002 as it should (no TAD device in DSDT), so this narrows the focus down to the Arm generic timer on secondaries. It’s unfortunate that the ‘rM’ command doesn’t dump any of the CNT MSRs with any mask (and the rdmsr command for Arm64 windbg is undocumented), so I can’t validate that register state is sane across all cores yet.

[falkor2k15]

How can I download and add a UEFI partition to my external hard drive that will allow Windows 10 on ARM ISO to boot up on a Raspberry Pi 3 B+? Has anyone managed to get KVM to work on qemu-system-aarch64 with graphics output at the same time?

[andreiw]

@falkor2k15 https://github.com/andreiw/RaspberryPiPkg/blob/master/readme.md#64-bit-windows-on-arm-17125rs4_release_prs180315-1454 has the exact steps you need to follow.

[andreiw]

@falkor2k15 Are you asking about Windows on Arm in a KVM VM? If so, https://withinrafael.com/2018/02/11/boot-arm64-builds-of-windows-10-in-qemu/.

[falkor2k15]

Wow, excellent work and nice write-up!

Wish I was more technical and less of a noob to understand... So the 64-bit Windows on ARM steps depend on first having the UEFI partition for Pi3 that you can then use to boot any ARM64 OSs, including Linux? Not sure why WinPE comes into it when we can just grab a Windows 10 on ARM ISO as per Rafael's guide? I must be missing a concept there. Most importantly, how can we get the UEFI partition on the Pi3? The link within "As a starting point, take the latest prebuilt image directories and copy to empty boot media" is currently broken. There is mention of EFI.fd files, which I am more familiar in a Qemu context, but the RPi3 supports only the following filetypes, including DTB files: https://s9.postimg.cc/kt2y2e3y7/firmware.png

Rafael's guide can run Windows 10 on ARM using Qemu, but only with KVM disabled (due to a problem with emulating the VGA framebuffer and a lack of VirtIO and other graphics drivers), so it runs extremely slow. This is using any ARM64 Host with a KVM-enabled kernel, such as Gentoo built by sakaki.

[andreiw]

@falkor2k15

Just to clarify, this has nothing to do with virtualization or KVM. RaspberryPiPkg is UEFI firmware for the bare metal Pi. Traditionally, Pi deployments either use no Arm firmware (Raspbian) or U-boot (openSuse or FreeBSD). RaspberryPiPkg allows booting 64-bit Arm operating systems that expect UEFI, such as FreeBSD, various flavors of Linux and (to a degree now) WoA.

Again, this specific thread documents getting Windows on Arm running natively on the Pi. No virtualization - Windows is started in EL2 (hypervisor privilege) and puts itself into EL1 (kernel privilege).

[andreiw]

@falkor2k15

Copy https://github.com/andreiw/RaspberryPiPkg/tree/master/Binary/prebuilt/2018Apr22-GCC49/RELEASE to an SD card and you’re off to the races.

[andreiw]

@falkor2k15

You can use a real ISO if you have one. I don’t. I can legally get the ADK (and you can, too), which lets me create a WinPE image that doesn’t need any I/O facilities to boot, it’s a ramdisk. Remember, that Windows ISO you have actually lacks drivers for the Pi, so by itself it’s not a great vehicle for developing Pi support.

To recap - no, you won’t be able to boot a stock ISO of Windows. Eventually, you may be able to boot an ISO that has the relevant drivers slipstreamed.

[falkor2k15]

I created a bootable USB from a working IMG file (compatible with Pi3 & Pi3b+). I then replaced the boot files on the small FAT32 boot partition with the ones from here: https://github.com/andreiw/RaspberryPiPkg/tree/master/Binary/prebuilt/2018Apr22-GCC49/RELEASE

I began by copying/replacing: config.txt RPI_EFI.fd That got me as far as the rainbow screen, but when I replaced the rest of the files my Pi3 fails to display anything: start.elf fixup.dat bootcode.bin

Could it be that those 3 are incompatible with my Pi3 B+ model board?

[diydavindra]

I wouldnt know to be honest but i found the best thing is to remove everything from that directory and transfer all the uefi files in. I found that worked for me but im not on a b+.