Windows Dev Kit 2023 Bootup

[jglathe]

This discussion is opened as a result of Windows Dev Kit 2023 Boot Work.

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[jglathe]

To get an idea how far away the current source code is from upstream, this is the comparision:

$ git log localfixes/jg/230616_testbuild_6_4_rc6...jg/ms-dev-kit-2023-v6.4.rc6 --oneline --no-merges
e22b687906e0 (HEAD -> jg/ms-dev-kit-2023-v6.4.rc6, origin/jg/ms-dev-kit-2023-v6.4.rc6, local/jg/ms-dev-kit-2023-v6.4.rc6) update devkit_defconfig amend Kconfig merge error
bcbad0f785b3 arm64: dts: qcom: sc8280xp-wdk23: enable pcie3a and add disable_pcie_3a config in dts
d530e6f6d07b Add README.md with tutorial from @chenguokai
e9e91387b760 arm64: dts: qcom: sc8280xp: Add GPU related nodes
e4daff1cfef5 arm64: dts: qcom: sc8280xp: add reset to soundwire controllers
b53f149fe779 clk: qcom: sc8280xp: add lpass csr driver
9ec42af7c8eb soundwire: qcom: set clk stop need reset flag at runtime
faf143f83f80 PCI: qcom: Add support for modular builds
18ce3d059239 Enable RFKill subsystem for bluetooth
396f82017a61 Enable mDP support for MS Dev Kit 2023
a43a98350ea9 Enable USB-A (dwc3 USB 2) ports
7cf312887986 Add Microsoft Dev Kit 2023 DT support
0a9ee8e334be arm64: configs: laptop_defconfig: Enable CONFIG_SECCOMP
9328f54d62df arm64: configs: laptop_defconfig: Re-enable CONFIG_QCOM_QSEECOM_UEFISECAPP
3ca3b2c377ff arm64: configs: laptop_defconfig: Update laptop_defconfig
cf086535932a arm64: dts: qcom: sc8280xp: correct GIC child node name
9958546d3113 arm64: dts: qcom: sm8150: drop snps,dw-pcie fallback compatible
fb55a96f0526 arm64: dts: qcom: sm8150: add missing qcom,smmu-500 fallback
8e59a73ed99d drm/msm/dpu: add HDMI output support
8b721fffc29b drm/msm/dpu: simplify intf allocation code
1e63ccd12649 clk: qcom: gpucc-sc8280xp: Configure CX_GDSC disable wait value
561ea6903b05 hack: bluetooth: add way to generate nvm name
e39489d75bf2 clk: qcom: Add sync state callback to all providers
3395e225b525 clk: qcom: gdsc: Avoid actual power off until sync state
176e754c02f3 soc: qcom: rpmhpd: Do proper power off when state synced
3a4602059258 PM: domains: Allow power off queuing from providers
87d544969b8d arm64: dts: lenovo-x13s: Make it hotter
c59423703a4f HACK: drm/msm/dpu: Give each CRTC a dedicated cursor and primary
b3278c217023 hack: power: supply: qcom_battmgr: Add present property
fe2568675a06 arm64: configs: laptop: Add laptop defconfig based on debian
ea1cb7943098 drm/i915: Add deadline based boost support
f9f3fb8e992f drm/syncobj: Add deadline support for syncobj waits
a4acc5b4e024 dma-buf/sw_sync: Add fence deadline support
552fda5dd176 dma-buf/sync_file: Add SET_DEADLINE ioctl
9bd8116bbd12 johan_defconfig: add custom config
682cedc5522d hack: arm64: dts: qcom: sc8280xp-crd: add wifi calibration variant
4e708bab6df1 arm64: dts: qcom: sc8280xp-x13s: enable UEFI Secure Application
39905f0d9884 arm64: dts: qcom: sc8280xp-crd: enable UEFI Secure Application
fd80a439a6db firmware: Add support for Qualcomm UEFI Secure Application
04b74f31c356 dt-bindings: firmware: Add Qualcomm QSEECOM interface
0b4ef6cee4f0 firmware: Add support for Qualcomm Secure Execution Environment SCM interface
da5c061bfc33 firmware: qcom_scm: Export SCM call functions
5912a8018b0b phy: qcom-edp: drop regulator loads
2380e2173bad phy: qcom-qmp-combo: drop regulator loads
2243f6206577 arm64: dts: qcom: sc8280xp: Enable GPU related nodes
faa9cc10f9c5 drm/msm/adreno: Add Adreno A690 support
2be5b1eb5862 panel: edp: Add LP133WU1-SPB2
0292a23b98ea ASoC: codecs: wsa881x: mute/unmute PA in correct sequence
8ec1f3c50693 ASoC: codecs: wsa883x: mute/unmute PA in correct sequence
0bbfeb0a8bde ASoC: qcom: common: add default jack dapm pins
6a33b082bf6e soundwire: qcom: add software workaround for bus clash interrupt assertion
bfa995f6dc1b soundwire: qcom: wait for fifo to be empty before suspend
bea5ba0db08c soundwire: qcom: enable runtime pm before controller is registered
ca50dac97d40 soundwire: qcom: update status correctly with mask
b9d32e089174 arm64: defconfig: build Qualcomm PCIe driver as a module
2d2cec88e8b3 ARM: qcom_defconfig: build PCIe driver as a module
2052e6003236 hack: efi: disable reset service
17ad9aa9c2d4 hack: disable has_address_auth_metacap and has_generic_auth
e189a447892a interconnect: drop unused icc_get() interface

IMO this is not very far.

[jglathe]

update: the latest 6.4-rc6 commit can handle pcie3a_gdsc as disabled. One kernel warning down, one to go. I would assume that the EDP warning is of a similar nature (somebody has hardwire-disabled the display port for LCD?). We'll see. Regarding the USB bootup issue, well, no cigar yet. Anyway, the wdk sometimes boots up pretty fast, and sometimes nvme is not detected either at root mount time. Adding rootwait as kernel parameter is a good idea as it seems. Also, need to do some detail work on all the missing vdda and vdd-pll regulators. All in all, looks a lot like device tree amendments to make the box behave better.

[jglathe]

update: Switched to 6.4.3 as development base. The EDP crash is now resolved, seems to work even on hotplugging and powerless screens. Those regulators are a bit of a mystery to me, I would welcome a schematic (block) diagram to make some sense of it. If you enable all regulators in the DTS, the box hangs with activating ldo3. More "unused hardware" effects? Also, the regulator configuration is from the Thinkpad x13s, which deviates from the sc8280xp-CRD a lot. Maybe it's not the optimal assumption, I'm try-and-error-ing my way forward. To compare and research™️ I have acquired a Thinkpad x13s, too. My gut feeling is that getting the power supply config right would also solve the USB bootup mystery.
Additional data point: The USB-C connectors limit current at 500mA, not enough to operate a RTL9210 USB to m.2 enclosure at full speed (will show up as USB2). On the USB-A ports it will operate at full speed (and gets 896mA). Since the USB-C connectors work at full speed with Windows, there needs something to be done, too. Oh well, maybe create some issues in this repo. Any help and commits are welcome.

[jglathe]

update: Got the X13s up and running with @armbian. Wheee! This thing boots from USB, and I think I found what was odd/missing on my WDK2023 setup. I think I will have it booting from USB in the next few days. rootfs detection by UUID works now. :)

[jglathe]

Now it's booting from USB :) I had it up with the @armbian USB stick with the 6.4.3 kernel added and an updated grub.cfg. The armbian stick won't boot as it is out of the box. The main difference was that the armbian kernel loaded mhi and mhi_pci_generic which didn't come up with the wdk:

lsmod|grep mhi
qrtr_mhi               16384  0
mhi_pci_generic        28672  0
mhi                    94208  3 mhi_pci_generic,ath11k_pci,qrtr_mhi

Previously this was only qrtr_mhi. Since mhi is another important bus on the chip, this seems like quite a reason why things behave oddly without it. It was compiled into the kernel, but apparrently it needs to be built as a module to work. Well, now it does. This changes the order of device initialization, and USB connected drives are available, also udev as it seems.
I will clean up a little, update the documentation, and push a new commit to the 6.4.3 branch.
Next issue up will be GLINK errors.

[jglathe]

And there it is: Now the code runs on 6.5-rc5 :-) Apparently most of the required stuff for the WDK is already in the upstream kernel, its just some dt stuff and the pcie3 disabling that is not:

e74635d808ca (HEAD -> jg/wdk2023-6.5rc5, origin/jg/wdk2023-6.5rc5, local/jg/wdk2023-6.5rc5) wdk2023: add devkit_defconfig file for building for this platform
6817e618f4c0 clk: qcom: gcc-sc8280xp: disable pcie3a in clock-controller
01212a3c82dc arm64: dts: qcom: sc8280xp-wdk2023: dt changes for WDK2023
2933805a9be3 cleanup of debian build stuff
0faf05dcdec6 Enable USB-A (dwc3 USB 2) ports
c36974a35a85 Add Microsoft Dev Kit 2023 DT support

So we're down to 5 commits as diff to mainline. Neat. I think it's ready for upstreaming :-) I guess I'm doing some testing first, though.

[sirredbeard]

I have a WDK and I am willing to help test and can get some others to help test too. Let me know how I can help. I'd be glad to write up a tutorial to on getting Linux booting on WDK.

[jglathe]

Hi @sirredbeard, welcome :-) Want to try out the USB image to boot directly to a live desktop? I just finished testing my bootstrap to avoid shipping with WDK2023 firmware files. I need to create an img, though, will take until tomorrow or so.

[likeadragonmaid]

I have WDK too, let me know if I can test it, I have some free time in weekends.

[jglathe]

Yes, of course. My tests with the firmware fetcher fail on freaking reboot, it sometimes destroys the file system. The firmware fetch actually works fine.

The desired course of events is this:

boot from usb, without firmware files
Linux balks about the missing files but reaches systemd
systemd starts and starts my fetcher script at basic.target, it will run and get the files from the windows partition
It will then deactivate the fetcher service in systemd, wait 10 seconds, reboot (or shut down)
I tried reboot, shutdown -P now, shutdown -r now. Also a sync. Grrr. This is annoying.
In more than 50% of the cases this will kill the ext4 rootfs. I will debug later on. The image is about 4gb, will be on google drive then.

[jglathe]

*** USB Bootable Image available ***

Now. I play it a little safer than I wanted, but this at least works without shredding the rootfs for whatever reason. You can find a bootable image here. The image is compressed 4,8GB, uncompressed almost 16GB. You can burn it onto a USB3 stick or (faster) an SSD attached via USB. Rufus should do, I used the disks utility from Ubuntu.

What's on it:

• Ubuntu 23.04 Desktop for arm64 - fully upgraded already,
• Ubuntu mainline kernel 6.5-rc5 with wdk2023 specific dtb and code,
• an EFI boot partition, installed with grub,
• a fetcher script for the wdk2023 hardware-dependent signed firmwares, inert, in /usr/local/bin .

What's not on it:

• the actual wdk2023 firmware files that are not in linux-firmware. Therefore the fetcher.

To make this workable I have compromised the security of the image: the root password is: FsecuritY!
Usually you boot this stick/ssd up, it looks like it won't work. It will take about 1..2 minutes (have a monitor on DP please), eventually the GUI will come up with the ubiquity installer. You change to VT-2 (Ctrl+Alt+F2), log in as root, execute /usr/local/bin/fetch_sc8280xp_fw.sh, reboot as you see fit.

For the adventurous: The systemd unit to fetch the firmware is /etc/systemd/system/copy_firmware.service. The script has a switch do_reboot, with set to 1 you can destroy file systems at your leisure (or find the bug).

Happy testing!

PS: I know that the raspi image is not the best choice. I am not familiar enough with all this linux stuff to make sense of debootstrap, though.

Known quirks:

• Bluetooth will not work with the builtin wcn6855, it did flawlessly with 6.4.3, though. Maybe some raspi-specific helper or something? Plugging in an USB Bluetooth dongle works.
• Sound is only usable via USB devices, works nicely then.
• DisplayPort works great, on Monitor resume you might have "hangs" of ~ 1 minute until it becomes responsive after waking up. It works, though.
• USB-C is a bad choice for anything that needs power. The definition is not complete yet. Use the USB-A ports if possible, they work well.

[likeadragonmaid]

Is it possible to upload firmware files somewhere on an unrelated gitlab instance just like TheMuppets do it? Secondly does the image boots and stays on usb or gets flashed on ssd of wdk?

[jglathe]

To the second question: It stays on USB. It's a live image. And yes, it boots. After fetching the firmware it is quite usable, depending on the USB SSD. It is way, way faster if you flash it to the local nvme ssd. @sirredbeard (?) and/or /me will add an updated tutorial to do this. Its not for the faint hearted, but can be made safe enough to allow for errors, backup options, the works. A good way to test it without flashing to local ssd is with an USB m.2 enclosure like the uGreen one with an RTL9210 chip. Use USB-A to connect to the SSD because of power requirements, otherwise it will only work as USB2. It is quite fast. 2,5" SATA SSD adapters should work fine, too.

[jglathe]

I won’t.

[likeadragonmaid]

Understandable

[jglathe]

What do you think why I spent a Sunday with ChatGPT hacking up the fetch script?

[jglathe]

And another update: now the firmware fetcher also works with systemd, without shredding the file system. It takes ~2 mins from first boot from grub to the setup screen of Ubiquity, including the reboot after fetching the firmware files. That is nice. Doing user-level reboot commands is a big no-no in systemd-run scripts. You need to do it this way:

[Unit]
Description=Copy wdk2023 files (signed hw-specific) to target path
After=local-fs.target
DefaultDependencies=no

[Service]
Type=oneshot
ExecStart=/usr/local/bin/fetch_sc8280xp_fw.sh
ExecStartPost=/usr/bin/systemctl reboot

[Install]
WantedBy=default.target

Yay, learned something. I will post an updated image for installation via USB stick. Same path on google drive as before.

[jglathe]

New image available here, Ubuntu_Desktop_23.04_wdk2023_6.5-rc5_fwfetcher.img.xz

[sirredbeard]

Back from vacay. Looking forward to testing this. Will be pulling out my backup WDK to test on, to not risk my daily driver.

[jglathe]

That's wise. A backup WDK? I haven't come up with that excuse to buy one, yet ;)

[likeadragonmaid]

Lol for me they have been out of stock since a while

[likeadragonmaid]

The image works exceptionally well! Good work 🎉 Bluetooth didn't work though and WiFi doesn't connect but at least I have Ethernet working just fine. :D I will try to increase rootfs size using gparted on an another Linux laptop lol

Update:

Gparted fails ¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯

[jglathe]

This is the 6.5-rc5 kernel not plyaying nice with the bluetooth stack. I can do an image with 6.4.3 and 6.5 (bleeding edge). Gparted works fine here... ? And grow root should run at first bootup. Interesting. Saw it running here.

[likeadragonmaid]

Ubuntu installer crashes while installing btw... Does it has something to do with it?

[jglathe]

Maybe, not sure. Found something re Bluetooth, still investigating. I will do the 2-kernel image anyway. I also have seen this installer crash, actually opened a bug report on launchpad. I‘ve seen it only once, though. Install commences after reboot and finishes.

[xlazom00]

I think that you should try armbian. They also have repo for firmware blobs :)

[jglathe]

Updated image Ubuntu_Desktop_23.04_wdk2023_6.4.3_6.5rc5_fwfetcher.img.xz is uploading to https://drive.google.com/drive/folders/1sc_CpqOMTJNljfvRyLG-xdwB0yduje_O?usp=sharing
This image contains both kernels. Grub should save which one was booted and use this one again. Should be up in ~30mins.

[xlazom00]

@jglathe can you rebase to 6.5 final plz ?

[jglathe]

will do. First things first, though

[xlazom00]

When I connect usb dongle (with image) to usb-c.
UEFI is booting fine
GRUB also fine
first parts of linux
and then display is disconnected
All fine with USB-A

[jglathe]

Seen the same here, cross-checking with the X13s and armbian.

[jglathe]

Actually, if it gets to mount the root and starts systemd, one could investigate with journalctl -b -1 when booted on USB-A after the failed USB-C, maybe it brings up something.

[jglathe]

ubuntu 23.10 image will be nice :)

Tried a little and no working stick yet. will add ZSTD support to the kernel (have it running on the x13s). A bit scared of the automatic changes from make menuconfig. The boots with 23.10 failed on interesting things - couldn't load any additional fw (no ZSTD support enabled, doh), so the bluetooth hack hung eternally... and no root backdoor to get a shell :( The kernel compiled with ZSTD works on the x13s, but something appears to have gone wrong on the stick... crashes, or sort of. No display. Killed my sdbox2 with do-release-upgrade -d with some interesting findings. This will take a few more days, I'm afraid.

[xlazom00]

They enabled this https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1942260
https://www.phoronix.com/news/Zstd-Firmware-Linux-5.19-Next
compressed firmware
so all firmware files are compressed with .zst sufix

I did do-release-upgrade -d from you 23.04 image
there was problem renaming /boot/EFI to /boot/efi

and then I saw all missing firmware errors :) But When I decompress them all works fine. I hope that when you enable that compressed firmware feature all should work just fine :)

I am now on ubuntu 23.10

[jglathe]

This gives me hope B) Had the same issue with boot/EFI. But before that step, a backup... anyway. Need some work to do, and some exercise, and sleep.

[jglathe]

Got it upgraded to 23.10 :) However, if the a660 firmware files are not there (it wants them uncompressed for whatever reason) you're f'ed, no graphics. Only switching vt and logging in, hacking from the console gets you out of this. And this could be because of an odd patch in the x13s/wdk specific commits, need to take a look at this. Also, the Bluetooth hack somehow didn't work at boot, but calling it directly sudo /usr/local/bin/set-bluetooth-address.sh worked.
All in all, a good outcome, I think I have a clue why my 23.10 stick was uncooperative. But, why, why, why. Why isn't the zst firmware thingy transparent? Like, fw_get_filesystem_firmware() automatically looking for both? There is still quite some work to do. Lots of cleanup to do. @xlazom00 uncompressing all was the better hack as it seems.

[jja2000]

Hi! Is there a list of firmware that needs to be fetched from Windows? I may have one or two ways to do it automagically (assuming internet is working without the missing firmware).

• Fetch a recovery image for volterra from microsoft and extract the image (haven't checked where it's supposed to be at, can't imagine it's hard to find though)
• Use Thinkpad X13s files where possible, something like qcvss8280.mbn is innoextractable from a driver install file from Lenovo's website

[jja2000]

Also for reference, they are fetched using the tool mentioned here: WOA-Project/Qualcomm-Reference-Drivers#3

[jglathe]

Thanks, I will try if they load and are the newest ones. Interesting, those repos.

[jja2000]

They are the newest ones on windows update. Qualcomm may have newer ones obviously, but this is the only place we can get them from specifically for Volterra. It would be wise to set an alert for any pushes to that repo in case they get updated.

[jja2000]

Also to give some context to the repo's, they're used as a reference for getting Windows on ARM to run on arbitrary (snapdragon) platforms. While some blobs/drivers are specific to Volterra, there are some that aren't. A lot of sc8180xp stuff works on sm8150 (a device example, and one that is supported by the project itself, the surface duo 1) with at most a bit of tinkering just to give an example. The same goes for sc8280xp and sm8350.

[jglathe]

That sounds like a good source.

[jja2000]

Hi @jja2000 , well there is sort of a list, it's sc8280xp-specific firmware, listed in the device tree source files

Thanks!

However, there is already a solution to fetch all files with this pattern from the Windows installation. If one wants to extend this solution to fetch from the wdk recovery image instead, yeah, why not.

The aspect of fw_fetch I'm struggling with is what the way of installing a different distro would be if you've already overwritten your Windows install with an earlier install of Linux. It would be nicer, apart from having the mbn's upstreamed obviously, to have a simple place to get the blobs from and using them on the device.

Considering the experimental nature of this, I would rather put the effort into getting the missing pieces to work. Like, there needs to be some work to be done to get the right calibration for the WiFi and Bluetooth setup, currently we're using the one from the X13s. It barely works :) Soundwire setup is also on the todo list, seems to involve firmware, too.

Entirely fair, I'm just here to get the user experience up a bit. I'm considering trying to get postmarketOS booting on the device, they tend to get the blobs either through TheMuppets (like someone mentioned here before) or by fetching them from a factory image. Instead of going for their approach by doing it in the package definition for Alpine/pmOS, I thought a more central/generic solution like you are doing may be better so others can use it too (if it works).

[jglathe]

There's a project on linux-surface which extracts a lot of firmware in different ways, and can work with recovery images. I would still prefer that @microsoft would upstream the firmware files, however that's their decision.

[xlazom00]

I think that you can put them here https://github.com/armbian/firmware armbian repo is open for everybody

[jglathe]

Was tinkering on the x13s with 23.10 to find why the userspace services won't run:

In both service units, you need to comment out ConditionKernelVersion="*-laptop" and start them.
As a bonus, sound started working over the internal speakers after the services were up. Yay. Now I get a <bonk> on every error :) To get these services to run on the wdk, do the same. I guess sound is approaching... ;)
The 23.10 install image for wdk is nearing usability. Still a bit baffled by this .zst firmware compression issue.

[xlazom00]

hihi firefox support only V4L2 H264 decoder :)
https://github.com/mozilla/gecko-dev/blob/master/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp#L388

[jglathe]

Yeah I've seen that too

[jglathe]

Mantic (23.10) Image with 6.6.0-rc6 is available now. Looks different. I have abstained from enabling ZSTD firmware compression in the kernel, don't understand it yet. I went @xlazom00's way and made a decompress firmware tree script with ChatGPT, appears to do the job. Also Bluetooth is a little odd, the systemd unit appears to be not working as expected. When you run /usr/local/bin/set-bluetooth-address.sh it comes up. But this only works after login, still investigating. Mantic officially supports the Thinkpad X13s, which is good. I expect more patches coming our way. Sound works over internal speaker on X13s now. There's hope we're not far away from getting sound via DP.

[xlazom00]

Are you able to get proper cpu temperature ?

[jglathe]

not with 6.6, but with 6.5.x. On the list to investigate... the more important part is that 6.6 does proper cooling, while I was able to crash 6.5.6 hard and repeatedly with a compile run. CPU temps were >85°C at that moment.
Also, there is np distinction between 23.04 and 23.10 regarding tis, something has changed in the device drivers on 6.6.

[xlazom00]

maybe it is somehow related to compressed firmware :)

[jglathe]

Gaaah. I just found an option I forgot to set on ZSTD compression. 6.6.0 is building....

[jja2000]

Can anyone running the device currently give me the output for sudo lspci -vvv for the wlan card? Trying something for wifi with the blobs I got from the Windows driver (Bluetooth will follow once I have more time to set mine up).

[jglathe]

Alright I think I got part of the way. Added some debug code in the ath11k core.c to get some better notifications. It loads the board data, but the fallback definition without variant. So, there actually is calibration data in the original board-2.bin file. The extracted one has a mixup on subsystem-vendor and subsystem-device, they are interchanged. Like it was defined in the json file (changed it there board-2.json).
I need to extract again with qca-swissarmyknife and the new board json, there is hope. Thank you for the help @jja2000 !

[jja2000]

Oooh nice, yeah ath11k picks a fallback based on the subsystem info the device gives. That's why a lot of the variant names you tried looked like they worked. Interesting that dmesg doesn't log the proper id's even on failure though (the first log you sent in the beginning of this thread shows it failing to use the volterra variant).

Let me know if you get any further! Due to time constraints I couldn't get my device set up sadly.

[jglathe]

I generated the board-2.bin with ath11k-bdencoder, and it finds the entry. But loading fails. Maybe the regdb entry needs to be created, too?

jglathe@snapdragix:~$ sudo dmesg|grep ath11k_pci
[    3.189116] ath11k_pci 0006:01:00.0: BAR 0: assigned [mem 0x30400000-0x305fffff 64bit]
[    3.189226] ath11k_pci 0006:01:00.0: enabling device (0000 -> 0002)
[    3.232238] ath11k_pci 0006:01:00.0: MSI vectors: 32
[    3.232279] ath11k_pci 0006:01:00.0: wcn6855 hw2.1
[    4.163056] ath11k_pci 0006:01:00.0: chip_id 0x12 chip_family 0xb board_id 0xff soc_id 0x400c1211
[    4.163060] ath11k_pci 0006:01:00.0: fw_version 0x110b196e fw_build_timestamp 2022-12-22 12:54 fw_build_id WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
[    4.506912] ath11k_pci 0006:01:00.0: ignore reset dev flags 0x8000
[   14.303142] ath11k_pci 0006:01:00.0: failed to wait board file download request: -110
[   14.303183] ath11k_pci 0006:01:00.0: qmi failed to load bdf file
[   14.303244] ath11k_pci 0006:01:00.0: failed to load board data file: -110

Anyway, I'll try a little further after work. What about all the other bdwlan files in this cat file? Decoys?

[jglathe]

Update, good and bad news:

good news: getting way better connection now, with the calibration data of the X13s (which appear to be "unique").

Bad news: All bdwlan files in the windows driver package appear to be incompatible, if not to say decoys. Only two files differ between the X13s and the WDK2023 package, except for the .mbn files (which are probably signed and whatnot). And these differing are incompatible for adding to the board-2 file.

I went through all unique .bin files being created by the ath11k-bdencoder tool when I extracted the board-2.bin file provided by linux-firmware. The only ones with the same subsystem vendor and subsystem ID are those from the X13S. I tried all others, these are the best (by a wide margin). Added both qmi-chip-ids I could see to the file. This board-2.bin is attached for everybody who wants or needs WLAN and BT. BT is also quite usable now, probably some interference thing.
board-2.bin.txt

Installation:

• download the file, rename it to board-2.bin
• sudo cp board-2.bin /lib/firmware/ath11k/WCN6855/hw2.0/
• reboot

I'm getting the 300Mb/s transfers, which is off course far from 900Mb/s but better than 50 (or worse). If there's a way to extract better calibration data from the Windows driver, we could improve further.

[jglathe]

In addition to this, to make it work you also need a newer dtb file:

sc8280xp-microsoft-dev-kit-2023.dtb.txt
sc8280xp-microsoft-dev-kit-2023.dts.txt

The dtb needs to be copied to /boot/dtbs/6.6.0-rc6+/ (use sudo cp). Afterwards you need to run sudo update-initramfs -u -k 6.6.0-rc6+ and reboot.

To re-generate the board-2.bin file locally (linux-firmware updates occasionally, too) this is also attached:

board-2.json

[jglathe]

Can anyone running the device currently give me the output for sudo lspci -vvv for the wlan card? Trying something for wifi with the blobs I got from the Windows driver (Bluetooth will follow once I have more time to set mine up).

Here you go:

0002:00:00.0 PCI bridge: Qualcomm Technologies, Inc SC8280XP PCI Express Root Port
0002:01:00.0 Non-Volatile memory controller: KIOXIA Corporation NVMe SSD Controller BG4 (DRAM-less)
0006:00:00.0 PCI bridge: Qualcomm Technologies, Inc SC8280XP PCI Express Root Port
0006:01:00.0 Network controller: Qualcomm Technologies, Inc QCNFA765 Wireless Network Adapter (rev 01)

Made on Mantic, has better device db

volterra_pci.txt

[jglathe]

Are you sure you rebooted into the DTB with the volterra compatible and the proper boardfile in place?
Yes I do. This is my history for a test run (after changing the dts file with sublime):

 1978  sudo dmesg|grep ath11k_pci
 1979  cd src/linux_ms_dev_kit/
 1980  time make -j8 Image.gz dtbs modules
 1981  sudo cp arch/arm64/boot/dts/qcom/sc8280xp-microsoft-dev-kit-2023.dtb /boot/dtbs/6.6.0+/
 1982  sudo update-initramfs -u -k 6.6.0+

And it creates a new dtb file.

[jglathe]

News as of now:

• rebased to newest 6.6.y tree from @steev
• devkit_defconfig is now configured with ZSTD and XZ firmware support, making it easier on 23.10.
• found a documentation error for the cron job for BT support on 23.10 - fixed now
• board-2.bin analysis for WLAN has resulted in a workable (but not perfect) calibration selection. Shout-out to @jja2000 for giving the inspiration. WLAN and BT are now real-world usable.
• will do a new 23.10 bootable image in the next days.

[jglathe]

23.10 image with kernel 6.6.0 and all hacks is now available. Tried the image with a completely restored wdk, all security as it comes after the restore. You won't get it to boot the image. You need to:

1. Disable Bitlocker and decrypt the drive
2. Disable Secure Boot in the BIOS
3. Enable boot from USB (as the first item in the boot order)

Afterwards, it will work (or should work), and will also fetch the WDK-specific firmware files from the decrypted Windows drive.

[jglathe]

Hmm actually I *did* a complete restore and boot with 23.10 (6.6.0) today. The restore didn‘t want to at first, I had to write the USB stick twice.  1. format the USB stick with FAT32 (GPT partition table) 2. unzip the recovery files directly into the root of the USB stick (I used 7zip) 3. boot with this stick and do the recovery , needs to go through. You get a clean, fully locked down Windows 11 on WDK 4. decrypt the internal drive (disable Bitlocker) 5. disable secure boot in the bios, enable boot from USB as the first boot order. Disable Windows boot manager in the boot order, too. 6. boot from Ubuntu Image. Worked after secure boot was off first time. Am 10.11.2023 um 23:05 schrieb Mick Cox ***@***.***>: Attached is 6.6.0-rc6; same issue. I'm not sure what else to try. I've tried to play around with settings in UEFI. Windows did recover properly from my USB stick though, and I did execute a clean install. I have used the 'Create a recovery drive' so I'm not sure if that formats the thumb drive as FAT, but given that Windows completely recovered I'm not sure if that has anything to do with this. I did update to the latest patch level with Windows Update after restoring though.

[jglathe]

😎 no, if the windows partition is not encrypted it will find and copy the firmware files, then reboot. No manual steps required. It is fastest from an SSD, from a stick it takes considerably longer, but works regardless. I tested both variants today. Am 10.11.2023 um 23:52 schrieb Mick Cox ***@***.***>: Turns out it is my monitor (Dell Ultrasharp 27 U2720Q) which was connected over HDMI over mini display (active) converter. Normally I use it through its USB-C port but in this case I had to use the converter. Using the same converter on our television works just fine. I'll try the 6.6.0 which you just released. Are there any other manual steps which one has to take in order to load all the firmware or is that done automatically? I couldn't find the fw updater but perhaps I didn't look in the correct place.

[jglathe]

This discussion is getting a bit hard to follow. Closing this one, the wdk2023 is officially booted up now :) Please open issues or discussions as appropriate. Will try and set up a wiki with the condensed knowledge to get things up and running.