I haven’t been able to go further (for now), but that’s a great start.
In case anyone for some random reason wants to repeat this, you can download this fip.bin and put it on an SD card’s boot partition after you’ve installed Windows on ARM on it (make sure to do that on MBR, not GPT), use bcdboot to create UEFI boot files.
If you want to access advanced boot options (the only thing that works!), use bcdedit command to enable it: bcdedit /store R:\EFI\Microsoft\Boot\BCD /set {globalsettings} advancedoptions yes
In U-Boot over serial, you can use eficonfig to add Windows Boot Manager and make it first in boot order, then use bootefi bootmgr to actually boot, good luck.
I quickly published the code, I’ll warn you that this code is definitely not production-ready or something, AI was used to help with porting, DSDT is not guaranteed to be fully correct, as well as the code has been modified since above fip-acpi.bin has been compiled, so it’s a little bit different (SPI/DTS were changed since then).
Don’t worry, I didn’t forget about it, thanks to my friend we managed to get kernel debugger connection working (the main reason is the AI generated ACPI tables were wrong) and now we’re actually getting a normal human-readable BSOD.
We will have native Windows on Milk-V Duo S sometime…
I ported a new version of U-Boot (latest 2026 main branch!) and my friend reworked ACPI, again.
As well, as I had to get more stable installation of Windows.
And now, Milk-V Duo Stechnically runs Windows 11 on ARM.
Just a few bare minimum processes, until it BSOD’s because there’s no driver to access the boot SD card itself.
Another fun fact: We actually kind of got graphics output, by coding an application that makes a screenshot of the screen and saves it to the SD card. While this is not the best solution, it kinda works, at least a bit.
To get better graphics output and user control, next logical step should be getting RDP. The problem in that not the RDP itself, but the lack of network at all, so logical step before that is working network, like a Ethernet driver.
Actually, previous Ethernet wasn’t 100% working - it didn’t receive any connections, other devices couldn’t even ping the Duo S, but that was fixed in the driver.
After Windows reinstallation fro Home to IoT Enterprise to get RDP - it doesn’t work.
The problem to that is RAM, which always was. The build WAS actually tested on 512 MB of RAM in a VM and it worked fine, only because of the paging file.
And Windows strictly forbids paging file on removable devices, such as SD cards.
This results in no paging file on Duo S and huge problems with lack of RAM, failing to run programs and no RDP.
Isn’t Server Core a headless system with no GUI? So winrm will only give you a oommand prompt
If so, I don’t see much benefits to doing that, since… We already have a command prompt through EMS over serial, and my next goal for fun would be getting a GUI
If you mean Server Core like a lightweight system to use less RAM - sure, it might help, and you’ll get a nice headless system
But my goal personally is not really use less RAM, I would somehow get Windows to make a pagefile anyway, get a GUI over RDP and have fun there
A lot of deleted stuff (Microsoft Edge, Windows Defender, tons of background services) and, of course, page file on the SD card, which makes it VERY slow (can take 30 minutes to just check task manager’s performance tab), but works.
To make it at least a bit more usable, next plan is making even smaller Windows, maybe use some Micro11 build that removes even more stuff so less RAM usage needed
hahaha, like using some famous rendering software on my 12MB 486 in the 90s…
Did you try some different SD cards (i.e. SanDisk max endurance - they’re slow but the data rates are kinda guaranteed? I don’t see if you got a usable USB (OTG) port, otherwise a USB SSD might also be better for the page file - it’ll always be contended for throughput of course, but you’d get a second disk queue (i remember when two 1GB drives with a page file on both was a really awesome setup ;-]
Happy hacking!
I’m a bit broke lol, I don’t have any other working SD cards or a USB SSD (and no USB drivers working anyway, at least yet)
I’m sure it might not even be using it’s full potential of the SD card though, the CPU is very busy with Windows bloatware, rendering the framebuffer and handling RDP over Ethernet, but the SD card driver doesn’t really seem to work with ADMA, so pretty much all reads/writes use even more CPU time…
