Windows 10 on RPI

Share here your ideas for new projects

Moderators: odroid, meveric, mdrjr

Windows 10 on RPI

Unread postby mad_ady » Tue May 22, 2018 8:05 pm

A bit offtopic, but: https://www.youtube.com/watch?v=6b1IxvKJeho
It seems you can run (unverified) Win10 x86 32bit on RPI by using a x86 emulator in uefi mode. I wonder if it could be adapted to Odroids (though they don't use UEFI). Not sure if there's a difference between Odroids/RPI in terms of requirements...

Edit: It seems to depend on this uefi build for rpi: https://github.com/andreiw/RaspberryPiPkg
Also, not clear if it's win10 x86 or arm64...
User avatar
mad_ady
 
Posts: 4937
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1

Re: Windows 10 on RPI

Unread postby crashoverride » Wed May 23, 2018 2:14 am

You should be able to run it on a C2 or N1 using QEMU (KVM accelerated) with the 'magic' UEFI firmware. However, there is absolutely no point in doing it. Drivers are non-existent for most things, the display is driven using the UEFI framebuffer (no acceleration), and its illegal in most countries (pirated software).
crashoverride
 
Posts: 4141
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1

Re: Windows 10 on RPI

Unread postby mad_ady » Wed May 23, 2018 1:22 pm

I am not very familiar with how UEFI works. I know linux and windows usually bypass BIOS and use the hardware directly and only DOS and bootloaders use BIOS API (interrupts). Is UEFI used as a middleware API by modern OSs? Or is it bypassed/unloaded shortly after boot? E.g. do you need to go through some specific uefi call to access the disk?
User avatar
mad_ady
 
Posts: 4937
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1

Re: Windows 10 on RPI

Unread postby crashoverride » Thu May 24, 2018 6:22 pm

mad_ady wrote:Is UEFI used as a middleware API by modern OSs? Or is it bypassed/unloaded shortly after boot? E.g. do you need to go through some specific uefi call to access the disk?

https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface
EFI defines two types of services: boot services and runtime services.


To better understand what is going on, the following example will be used:
https://withinrafael.com/2018/02/11/boot-arm64-builds-of-windows-10-in-qemu/
Code: Select all
qemu-system-aarch64.exe ^
-M virt ^
-cpu cortex-a57 ^
-smp 3 ^
-m 4G ^
-pflash QEMU_EFI.img ^
-pflash QEMU_VARS.img ^
-device VGA ^
-device nec-usb-xhci ^
-device usb-kbd ^
-device usb-mouse ^
-device usb-storage,drive=install ^
-drive if=none,id=install,format=raw,media=cdrom,file=.\17083.1000.180119-1645.RS_PRERELEASE_CLIENTCOMBINED_UUP_ARM64FRE_EN-US.ISO ^
-device usb-storage,drive=drivers ^
-drive if=none,id=drivers,readonly=on,file=.\drivers.vhdx ^
-device virtio-blk,drive=system ^
-drive if=none,id=system,format=raw,file=.\system.vhdx


An ARM Cortex-A57 virtual machine (VM) is created. Virtual hardware is attached to this VM: VGA, USB interface, USB Keyboard, USB Mouse, and USB storage devices. The VM is configured to boot a (custom) UEFI image. This UEFI firmware boots and find the virtual VGA, USB, and USB devices. It then continues booting from the ISO image. The ISO image (presumably) utilizes the UEFI runtime services to continue further operation. Once the OS is up and running, its (custom) drivers take over and directly use the virtual hardware.

Note that a recent QEMU is required (such as found in Ubuntu 18.04) and, on ARMv8 systems, KVM can be used with a host CPU type. On big.LITTLE procs like N1, the qemu task must be pinned to a cluster for KVM operation since the host CPUs differ (Cortex-A53 + CortexA72).
crashoverride
 
Posts: 4141
Joined: Tue Dec 30, 2014 8:42 pm
languages_spoken: english
ODROIDs: C1


Return to The Ideas

Who is online

Users browsing this forum: No registered users and 1 guest