Most people will probably want to run Linux on their Arm SBC, but Windows 11 could also be an option with the Rock 5B and other single board computers based on Rockchip RK3588 and other powerful Arm SoCs thanks to the Windows on Raspberry project.
The project, also known as “Windows on R” is maintained by Mario Bălănică who recently tweeted a screenshot showing Windows 11 running on the Radxa ROCK 5B SBC powered by a Rockchip RK3588 Arm Cortex-A76A/A55 clocked at 1.2 GHz (instead of the usual 2.2/2.4 GHz), but with USB 2.0/3.0 and display interface apparently working just fine. PCIe appears to be detected, but not working.
He also noted that virtualization worked out of the box unlike with Raspberry Pi 4 SBC showing Windows Subsystem for Linux (WSL 2) and PowerShell in the screenshot below.
Virtualization also enabled running Android apps in Windows 11 Arm as shown in the screenshot below with Angry Birds.
I’d assume there aren’t any drivers for the GPU and VPU however, so it might be sluggish, but no video demo was shared. Geekbench 5 could run fine, but since the processor is clocked at 1.2 GHz the scores are lower than in Linux or Android.
The code is still working in progress, and Mario told people to check the project website and the GitHub repository for updates, but I was unable to find anything about Rockchip on either at this time. A thread on Radxa’s forum points to an EDK2 UEFI port for RK35xx targets which was apparently used to boot Windows 11 on the Rock 5B.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
No sympathy for Redmond.
Microsoft-Redmond, I guess? Not to be confused with Calista Redmond – CEO, RISC-V International
You now its worth it when companies start to replace Intel, AMD etc. Till then its a gimmick.
> A thread on Radxa’s forum points to an EDK2 UEFI port for RK35xx targets
In Geekbench comparison mode the UEFI version (wrongly called BIOS) can be read: EDK II 116910a4.
As long as there is not a PCIe attached GPU added with working ARM drivers this Windows port is as useless as a Desktop as any other running on SoCs w/o DirectX/Direct3D support (which AFAIK still is a Snapdragon/Adreno only feature?). But this would require PCIe working first and such a setup makes no sense anyway.
You cannot say this like that. Tkaiser you are a very competent guy, so you know that running this gaz facilities of Windows on ARM cores is still impressive ! Remember, these chips are running from small batteries, eating just a tenth of power. I am playing with the RK3588 for month now and I can say, it’s a beautiful chip, and I know you have a lot of fun with it too 😉
> running this gaz facilities of Windows on ARM cores is still impressive
What’s impressive? Once this insecure monster called UEFI is up and running on ARM and the CPU cores meet minimum requirements Windows can run too since the Microsoft guys ported their stuff to ARM a while back. Though the user experience as desktop OS is crap unless GUI acceleration works properly.
IMO the only impressive thing is Microsoft doing x86/x64 binary translation on ARM rather elegant though not that efficient compared to Apple on their own silicon.
What Tkaiser is saying it’s what everyone would say. WoA sucks without vpu and gpu drivers, but mostly with the latter one. Without gpu drivers it’s useless. WoR was useless, still useless today. If they manage to get windows arm mali blobs that’s a diff story. As it stands, it’s not impressive at all.
What value does running Windows on this hardware bring?
I can see why someone would want to run Windows on x86. Windows on ARM? NOT SURE. Maybe it’s better at emulating Windows x86 binaries (after a long period of time when it was 32-bit only IIRC).
> Maybe it’s better at emulating Windows x86 binaries
It’s binary translation BTW and the key to sufficient ’emulation’ performance is most of the executed code parts being native ARM (kernel, DLLs, dealing with acceleration engines) which requires Microsoft’s media APIs (DirectX and friends) being supported by the GPU in question otherwise any ‘Desktop experience’ will be none.
A few decades ago, when Windows was ported to Alpha, there were some demos featuring the DECpc at 150 Mhz outperforming the fastest 486 available by then despite running emulated x86 code. In fact, when a CPU is fast, the whole (native) operating system is fast, emulation remains acceptably fast and the result is good.
To be able to run windows apps on a $90 piece of hardware that uses <15 watts.
I’d love to have windows on arm on a mac mini. I love the hardware, performance and watts used, but I can’t stand Mac OS.
Microsoft has a windows on arm developer platform, but its half the speed of a mac mini and costs the same.
> I’d love to have windows on arm on a mac mini. I love the hardware, performance and watts used, but I can’t stand Mac OS.
Then get Parallels Desktop! They somehow managed to let you run Windows 11 legally on Apple hardware and to emulate DirectX 11 on M1/M2 Macs. Though if your Windows apps require DirectX 12 you’re out of luck but at least the stuff I’m missing in macOS (ransomware mining crypto currencies for someone else and a virusscanner totally destroying performance) should not rely on DirectX 12!
> To be able to run windows apps on a $90 piece of hardware that uses <15 watts.
When I google Radx Rock 5b, I get prices of € 200 and higher?
So then I prefer an x86 NUC.
It’s really just a curiosity experiment at the moment.
But if the drivers for the full hardware were available then you’d have an actual desktop OS platform and not the usual half baked attempts at a linux desktop distro, that makes all the difference.
Right now MS is partnered with Qualcomm but rumours suggest Mediatek wants in on Arm win PC’s too which would provide Mali drivers. If the drivers ever become available watch as all the new SBC’s use windows as their main selling point.
> rumours suggest Mediatek wants in on Arm win PC’s too which would provide Mali drivers
Which Mali GPU provides at least DirectX 12 FL12_0 compatibility?
UEFI is a prerequisite for running any ‘ServerReady’ linux distro. So studying how Windows does it may flush out bugs in one’s EDK2 port. Otherwise, it’s wishful thinking that the developers of Windows 11 would take notice and ‘fix’ anything such as providing drivers.
Rather than bare metal, perhaps running Windows in a VM with virtio would provide better (paravirtualized) hardware access.
> UEFI is a prerequisite for running any ‘ServerReady’ linux distro.
It’s also a prerequisit for persistent malware and one of the many reasons why x86 is considered insecure by design: https://youtu.be/iffTJ1vPCSo?t=94
What is this exotic operating system with its 3-color window manager trying to poorly emulate KDE used for ?
Other than that it’s great to see the ecosystem around Rock5B continuing to evolve, it’s a great board, which was designed with a lot of care for the feedback from the community, so it’s totally expected that it gets some love.
> so it’s totally expected that it gets some love.
I guess this is more related to Windows 11 after build 25163 not running on the RPi 4 any more (since making excessive use of ‘the new atomic instructions introduced in ARMv8.1’ too new for the Pi’s A72 but ok with RK3588 basing on ARMv8.2 A55/A76 cores) and the state of the UEFI port for RK35xx compared to the VideoCore thingies Raspberries rely on.
If so, that would be a good thing for us, the consumers, as it means the days of ARMv8.0 are counted. The atomic instructions relying on LL/SC are such a pain in terms of scalability that I hope that 8.1 will become the new de-facto standard soon. I.e. if everyone starts to sell A55/A76, the performance gains could encourage distros to shift to that by default at some point. Also, even when being careful, the risk that some software uses them by default is never nul and it’s likely that sooner or later we’ll start to see threaded programs breaking on v8.0, pushing A53 and A72 closer to the door.
> it means the days of ARMv8.0 are counted
I don’t think what happens in Redmond has any meaning for the broader ARM world. IIRC the first WoA 10 hardware was based on Snapdragon 835 (announced in late 2016, custom A53/A73 cores) but already one year later the 845 brought support for ARMv8.2 with custom A55/A75 cores.
Microsoft just stopped supporting 1st gen WoA hardware with Win11 recently.
We all know it was and is just a pretend Windows skinned Linux, initially for Raspberry farts ( past their sell by date and leaves a bitter taste. ) machines.
Whilst the real barrier to this right now are the drivers, only a few years ago I suspect that the idea of a working 3rd party solution such as Panfrost/Panfork would have seemed like a pipedream to many, and yet ….
So this is impressive in it’s own right and we will just have to see what time and development brings in terms of Windows being a fully practical use solution on this SOC.
> Panfrost/Panfork
Why do you mention such projects in this context? Don’t you think on this SoC now and most probably forever Windows will just use the MSBDD to paint pixels onto the frame buffer set up by UEFI?
Arm has Windows Mali drivers for many of their accelerators, just that they’re not public.
There are some other upcoming SoCs with Mali that could receive Windows support: NXP i.MX which recently got open-source Vivante GPU drivers based on DXVK, and Mediatek.
Even if it never gets GPU drivers, it’s not that big of a deal as to render it useless. There are a lot of scenarios which don’t require acceleration at all. MSBDD is usable for basic 2D tasks (and even same games, lol).
As for the UEFI, the malware argument is just a bad excuse at keeping Arm tied to distro-specific DTs, which in its essence won’t ever allow it to truly become a PC. UEFI is only insecure if it’s poorly implemented / the manufacturers don’t bother to secure it, but do we even care about this on a platform that’s really just meant for tinkering?
Isn’t this what the SBC world is all about? Having fun making or porting things? It’s not like they’re trying to sell a new PC alternative with Windows that just barely works, you can’t expect it to fully work from day 1. On Linux you’re still stuck with the pseudo 5.10 kernel if complete functionality is desired, for more months to come.
I generally agree. While I hate UEFI for being a huge pile to bogus crap everywhere I have to deal with it (essentially PCs), we do need a standard way to boot ARM boards and to provide generic access to their devices, exactly like the PC’s BIOS did that in its time. Device Tree can definitely provide hardware description but it would require that vendors provide one with their boards instead of relying on the distros to provide one. Also one problem is that Linux is the official repository for DTs, and that does not make sense if it’s meant to describe hardware in a software independent way. U-boot provides boot functionality and can rely on the DT provided by the vendor. It does implement drivers but does not offer them via services for generic operating systems since it’s not meant to stay resident. So we’re still missing the BIOS-equivalent that allows to access devices (storage, display, USB, network etc). The UEFI turd is what provides all this, allowing to boot a generic OS with either generic or specific drivers. Do we need better ? sure. Do we have better ? no. Will we have better ? Sadly I don’t think so, given that every time someone wants to address problems somewhere, they invent something even more complicated and the complications are the roots of all the trouble.
> Arm has Windows Mali drivers for many of their accelerators, just that they’re not public.
Who will pay the license fees for RK3588? Radxa? Those people who want Windows on ARM for the sole reason they dream of something that smells and feels like a typical x86 Windows PC just being as cheap as possible (which Rock 5B isn’t even BTW, only when looking at totally irrelevant list prices that apply to no regular buyer on this planet)
It’s obvious that right now you should just be looking at x86 boxes if you want something that works and it’s relatively cheap. (but 3588S also exists and it’s generally faster than what you can get in x86 at that price, used)
Again, these efforts are more of an experiment than anything at this stage. If something comes out of this, that’s good. If not, still good.
> but 3588S also exists and it’s generally faster than what you can get in x86 at that price, used
On this specific point I disagree. The faster you get for a small price is refurbished hardware such as Lenovo thinkcenter or HP microservers, which are usuall sold for less than $100 for 4G+64G SSD and a core i5. That is more powerful than the RK3588 and much less restrictive on the choice of operating systems. RK3588 can serve as a great basis to create new products however. Its real value for us users is mainly to provide great ARM development boards at a reasonable price.
The i5 processors I see in those old Microservers are a bit slower than the 3588(S) in multi-core perf and less power efficient. iGPU also seems much weaker.
The Rock 5A (with 8GB RAM!) currently presales for about $89 USD. Orange Pi 5 was a bit cheaper than that if I remember correct. Yeah, no storage and connectivity is more limited.
I do agree that x86 machines are still more convenient right now, software is a big part of it.
RK3588 is as fast as an I7 10th generation Willy. It takes less time to compile Kodi than smoking a cigarette, and handle less than 60°C on simple polished dissipator without fan.
I do have a rock5b and your numbers are exagerated. What I found is that the A76 on this board are roughly equivalent to skylake cores running at the same frequency. That’s already a great achievement, but it doesn’t need to be exagerated 🙂 you can have a look here where I maintain a collection of build performance tests on various boards: http://wiki.ant-computing.com/Choosing_a_processor_for_a_build_farm#Results
RK3588 there is 20% faster than the Odroid-H3, which is twice as slow as the 8th gen i7 in my laptop.
By chance, Eta Prime has a RK3588 emulation video up today, Willy. This real world video, puts it all in perspective better, for non honest RK3588 promoters. Its over on YouTube
“The Rock Pi 5 Can Run Steam Games! PC Games & EMUs On An Arm Based SBC”.
Hahahahahaahhahaa
> It’s obvious that right now you should just be looking at x86 boxes if you want something that works and it’s relatively cheap.
At $dayjob we’re fine with ARM… and honestly don’t care whether a MacBook relies on Intel inside or Apple Silicon as long as it does its job for many many years. We’re still upgrading users of 2012 MacBooks with M1/M2 machines even if we suspect the early M1 hardware getting macOS updates for only 4-5 years so we’re betting on proper *BSD support then.
> As for the UEFI, the malware argument is just a bad excuse
IMO it’s not. The ‘E’ (Extensible) makes it insecure by design. This is just the sad reality with everything that runs UEFI. As it’s the sad reality with upstreaming ARM hardware the DT/Linux always taking way too long since the whole process could be best described as ‘broken by design’.
The video you posted above mostly talks about issues with the vendor implementations themselves (like the fact that they’re closed and proprietary, but EDK2 is open in fact). Nothing really related to UEFI per se.
If we talk about vulnerabilities, every piece of software has them. Linux does, U-Boot does, etc.
For now, I am still fighting with AV1 and mpp, I would love to have more time to spend on it…