I guess people should encounter situations on DGX Spark like when Windows consumes huge part of scarce RAM for its own purposes or interrupts a long-running agent session to force-install OS updates - in order to realize how poor Windows could be as a Spark OS.
But yeah, maybe finally we’ll get something newer than 580 driver or CUDA 13.0.
Nobody is asking for engineering resources for Windows. The amount of work needed for "Windows support" is close to nil.
They already made their point clear. Windows support is not supported on DGX Spark. Meaning if there is an issue with it then they aren’t going to waste support resources on it. I don’t care about that, I just want them to not make it not work, which isn’t exactly an insane ask, seeing DGX Station heading to Windows (explicitly) and RTX Spark being the same silicon.
On the GPU Driver, it already works on non-RTX Spark GPUs, i.e. someone tried an eGPU before on ARM with it so the support is there (although it was wonky, lots of possible reasons) so again, it is really just whether or not they will actively deter it.
You can build 26H1 ISOs and it still won’t matter, you lack the system drivers for exposing the layout / devices (which is why the other person who tried couldn’t find the SSD).
Recovery ISOs will 100% be public, OEMs and Enterprise will use them and there is little reason to hide them once devices become public, and if not people will make ISOs and then it becomes an issue of not having an official one. For example, Microsoft’s existing ARM devices have public recovery ISOs - gated behind a serial number requirement.
I mean it’s not like NVIDIA doesn’t have the resources, the DGX Spark is 1 machine and very similar to the RTX Spark.
It should be done as a matter of supporting customers who wish to run a secondary OS, given they are going full speed ahead with Windows 11 support for the chipset.
I can’t say anything on NVIDIA’s part and they’ve made it clear it isn’t on the list of things to have as a first class citizen.
I can only say based on what I know. There’s more reason than not to believe that it should work just fine (same silicon, PCIE communication is standardization, Linux is actually SBSA - basically point is they already have the standardization bits done, let’s just say the benefit of the doubt Windows has not adopted that standard on consumer Windows so that’s already out the window).
At the same time from the above you can pretty much tell how easy it is just shut off the valve as well. No SoC driver, up to maybe some perverse hardware check.
Same on the RTX Spark side, they can just kill off Linux support by removing the SBSA support and not providing a device tree (i.e. how Snapdragon is supported).
Anyway I have procured some W11 ARM drivers that appear to be what I need from an OEM RTX Spark. Now tell to see if it is plug and play.as
Tried a couple variations, unsure if there is a hardware lock on the drivers.
Booting custom ISO lands me into Driver Violation but same ISO doesn’t violate on another Arm device. Base ISO without those drivers boots fine on both (but then no storage).
Well, guess I’ll wait for an official recovery ISO from MSFT and if it still fails then it’s probably some check crapping out on the dgx spark.
Tried UUPDump 26H1, previous 25H2, and current 26H2 official ISOs
Thats a shame
If the RTX Spark works on Linux Day 1 I’m probably going to need to take a few days off work and literally fume and give a complimentary “F you” like Torvalds.
You have to clean through the Drivers to axe the OEM drivers / optimizations - wasted a few hours trying to reverse engineer before Claude brought up the fact that OEM drivers might be mixed in the pack.
I am unsure which subset is needed, but I have managed to get SSD detected
25H2 ISO USB with only the NVIDIA drivers (SoC subset, not GPU display) has the SSD detected and USB keyboard working. TPM detection failed, bunch of reasons but TPM is not strictly necessary for Windows install and use, will see how bypass fares
25H2 doesn’t have the right kernel optimizations AFAIK. 26H1 is supposed to be the one to use for GB10/N1X but it doesn’t work. I tried 26H2 as well, but get the same issue: integrating drivers gives me a DRIVER_VIOLATION though the 2600 versions seem to be buggy for manipulating the install image if it’s not made from the genuine ISO (not even the ESD ISO from the Recovery Media Creation Tool.
These are the drivers I got from the driver pack for an HP Omnibook 16 (bk000000 model):
GPIO\nvgpio.inf ACPI\NVDA9221
I2C\nvi2c.inf ACPI\NVDA0200
MeTelemetryKMD\nvMeTelemetryKMD.inf ACPI\NVDA8800, ACPI\NVDA8810
OfflineCrashDumpDriver\nvOfflineCrashDumpDriver.inf ACPI\NVDA8888
SPI\nvspi.inf ACPI\NVDA0210
SROOT\nvsrootMbx.inf ACPI\NVDA8600
acxsoundwirecontroller\nvSoundWireControllerDrv.inf ACPI\NVDA9100
acxstreaming\nvasd.inf ACPI\NVDA9021, ACPI\NVDA9022
anvadsphpsign\nvadsp.inf ACPI\NVDA8300, ACPI\NVDA8301, ACPI\NVDA8302, ACPI\NVDA8303
upep\nvpep.inf ACPI\NVDA6210
xhcifilter\nvxhcifilter.inf ACPI\NVDA8000, ACPI\NVDA8001
(I got my Hermes Agent to extract them, so I hope it’s right.)
GPIO I2C SPI and rest go poof if same as mine. That will give you SSD / USB control. You need Mediatek drivers for WiFi / Bluetooth.
Anyway as a full disclaimer to anyone else, GPIO, I2C, and SPI are quite sensitive controls, meaning your device can go poof (again this is betting on same silicon, ~same tolerance, ~same controls)
That gives you a Windows Installation. Unfortunately nothing will give you a proper NVIDIA GPU driver so it is half baked. The install I have verified was on top of 26H2 (latest public Windows ISO).
I am running a 26H1 install right now so will see if it works out (mostly to see if the TPM is detected in 26H1 then it is just an issue of the old kernel/codebase not supporting a new method). Pretty much as expected, TPM is detected on 26H1 and not 25H2 / 26H2 (ARM FF-A method of TPM or something) anyway not an issue since it is easy to bypass either way, but installing through the GUI walkthrough will require 26H1 for the TPM to be properly detected
I don’t expect any real benefit unless the NVIDIA GPU driver is gated for 26H1 but I don’t even think the INF allows for the GB10 GPU (but the prerelease allowed eGPUs and apparently so does the current release so go figure I guess).
For CUDA it may work if you allow unsigned drivers and force change / allow the INF but that’s not something I’ll check. So unfortunately I’m still at the whim of the NVIDIA gods.
If you don’t mind me asking, where are you getting your 26H1 base images from? I don’t have an RTX Spark to try to extract an installation image from it, and the only place I can find where you can get one from is UUPdump, though it’s just hacked together. I don’t have any paid Microsoft subscriptions (Technet or MSDN) to get official ISO’s either (do they even have 26H1?), and it’s not on the regular Windows Software Download website at microsoft.com/software-download - only 26H2 for ARM64 is. I’m gonna try another attempt with UUPdump with 28000.3231 and see where that gets me. I have a feeling they’re missing something though.
I’m tempted to just order an RTX Spark to dump a real recovery image and send it back under a return policy.
I’m speculating that nvidia designed the GB10 initially for desktop-only platforms, mainly to get developers working for free on it, but it needed a minor hardware mod to support windows without degrading performance in some way. The specs of the GB10 and N1X/N1 are basically the same, and if the GB10 could have run Windows optimally, they would have released it months ago. Memory prices are going to keep it from broad adoption anyway.
It’s the same silicon, except they’re offering scaled-down variants. The difference is likely just in the firmware, though they still have ACPI w/ UEFI and even a Microsoft Secure Boot certificate preinstalled (Ubuntu Secure Boot supports it and computer vendors haven’t had any luck with Linux vendors coming up with standarded certificate chain for Secure Boot because of pushback over binary ROMs). There’s probably some small system-level firmware changes for interrupts or something like that, and I haven’t looked at all the PnPID’s for hardware in the GB10 to see if it matches the ID’s in the RTX Spark driver INF’s yet.
Yes either a RTX Spark device or UUPdump is what’s left. I would also wager there’s something in Visual Studio Subscription but yeah if no paid subscriptions. Otherwise an “official” 26H1 ISO will have to come in some form of recovery ISO (MSFT will likely have one, when, not sure)
How did you install the drivers? I figured you probably had the right way but you should be injecting into boot.wim (and at that point might as well for install.wim since it only costs a few extra minutes).
Anyway I’ve tried a bunch of NVIDIA driver installs and the GPU is a lost cause. ARM features are detected and working fine though, WSL + Sandbox is what I tried. (not even the force device bypass those eGPU folks have found, the ever reaching error code 43 - did not try any nonsigned driver INF hack workarounds which has some success based on reddit posts)
First I got a copy of UUPdump 26H1 (built 2000-something). I just built the ISO normally to see if it had any NVIDIA drivers in it.
It didn’t. It comes up and says “Insert disk for hardware support”. USB didn’t work either, so no keyboard or mouse, nor would a USB stick help. With a wired backlit keyboard, I can see when WinPE starts loading, USB just shuts off.
So then I looked around for RTX Spark driver downloads. I checked for the ASUS ProArt 16 unit. It has a MyASUS WinPE recovery mode image. So I grabbed the boot.wim off it and just replaced the one on my ISO with that one, figuring the drivers for RTX Spark are all included. They were, but it gave me the aforementioned DRIVER_VALIDATION error.
So I extracted those drivers, and put them into the UUPdump drivers folder, changed the script to get it to add the drivers (otherwise it ignores them), and rebuilt the image. Same error as the WinPE image.
I tried reducing the number of drivers, but any time I included any of them, including the PEP driver, and the motherboard core driver, or even the XHCI driver, it gave me the same error.
So I went back online and found the HP Omnibook Ultra model, downloaded their driver packs, and bundled them into the UUPdump script. Same error.
So then I tried just rebuilding a generic image and using DISM, mounted the boot.wim and played around with the drivers manually. Same error. The command is dism /image /mountdir: /add-driver /driver: /recurse (when using subfolder)… then commit and dismount.
I tried a 26H2 image just to compare, and it’s the same result: both the ASUS and HP drivers cause a DRIVER_VIOLATION error when any are injected, and without any drivers NVMe isn’t detected, and USB shuts off part way thru the WinPE loadup and it wants a driver disk that I can’t put in or access.
It’s possible that the USB ports getting shut off with the generic install is the reason why NVMe isn’t detected - it could be that the computer isn’t able to read the other drivers on the disk.
The current UUPdump that I’m trying is the 28000.3231.arm64.en-GB (English International because I’m in Canada and that’s the base language pack for Canada - the other is US English). I’m gonna give it another go after I finish this message.
You’ve gotten further than me though. I can’t even get Windows Setup to boot. I don’t have any 25H2 ARM64 images either. Did you not try the ARM64 Windows beta GPU driver in the forums? The models of computers I mentioned should have RTM drivers on their support pages too.
I have a feeling that because this is a special hardware release, Microsoft isn’t going to release ISO images for them. So far from what I’ve read, the OEMs are all using some kind of Internet recovery support in firmware (Dell and HP already offer that on other machines), or else in the recovery partition on the drive (like with Asus where it’s just a WinPE image that downloads the install image through their backend server).
Will update with details of the most recent install attempt.
I just tried creating a 26H2 with the HP drivers and it works fine for me on Setup? I did not proceed with the install because I already have 2 VHDXs with 26H2 and 26H1 now but keyboard and disk is detected (diskpart > list disk).
So then I tried just rebuilding a generic image and using DISM, mounted the boot.wim and played around with the drivers manually. Same error. The command is dism /image /mountdir: /add-driver /driver: /recurse (when using subfolder)… then commit and dismount.
This sounds right so unless you screwed up this shouldn’t be the problem.
If you are getting DRIVER_VIOLATION you are adding a driver you are not suppose to (I don’t not verify but Claude says others interface with firmware or look up values that are just possibly not found in DGX Spark which is plausible). Just add GPIO, I2C, and SPI from the Core Driver set and the Mediatek Wireless and Bluetooth driver (so 5 total).
Also disable sleep in Windows, one of the core drivers probably handles sleep policies and power states so it never wakes up when it sleeps, either that or not having the NVIDIA driver means the monitor never wakes back up.
I tried 616 and the latest 617 for NVIDIA drivers. The INF is likely (well I ripgrepped the Device ID and it was missing but not a Windows geek) missing either way.
Microsoft will have an ISO, I guess you can say it may not be public but there will be ISO. Anyway it isn’t the end of world, 26H1 is 28XXX, the latest Insiders experimental is already 29XXX so there is a unified branch already.
I think I tried that combo before and still got a driver violation. I’ll give it another shot. Are you injecting the drivers with the /forceunsigned parameter? DISM help says that’s for x64, but I wonder if they ever updated the commandline help for it
Also, I do see 26H1 on MSDN and VStudio subscriptions (but only full-priced retail and annual VS subs because monthly ones don’t include software). No cheap way to get it. 😞
All these drivers are already signed, we don’t change anything, so there is no reason to inject /forceunsigned. I’m just guessing but you might have been violating Secure Boot with that possibly?
No I wasn’t using that option.
Try removing the Bluetooth driver. Mine wasn’t picked up because it was in a folder within a folder. I don’t see anything else that is different in the HP driver install.
Otherwise just try the core GPIO + I2C + SPI because those are the only parts needed for Setup / Boot / Install. WiFi and Bluetooth can always be installed later.
I am not sure why you are getting DRIVER_VIOLATION.