surface-pro-x
surface-pro-x copied to clipboard
linux-surface
General Discussion
I spent some effort to enable KVM for Linux on Surface Pro X but didn't succeed so far. Maybe this deserves its own issue.
By default Linux boots in Exception Level 1 (Supervisor Level).
In order to enable KVM, Linux must execute in Exception Level 2 (Hypervisor Level).
My guess is that the UEFI Firmware is configured to boot every image (Windows Bootloader, USB Media, etc) in exception level 1.
However Windows for ARM includes a functional Hyper-V (which requires execution in EL2).
There must be a channel to unlock instruction execution in EL2.
The boot procedure on Surface Pro X looks similar to x86_64. UEFI FIRWMARE -> bootmgrfw.efi -> winload.efi -> hvloader.dll ... _xeroxz describes it here https://git.back.engineering/_xeroxz/Voyager
There is a lot of assumption below: The first method to execute arbitrary code in EL2 would to via a synchronous exception call to EL2 (HVC). Instruction address can be passed via general purpose register. This require a specific exception handler at EL2 which branches to the instruction address.
The second method is similar to the first but via the secure monitor in EL3 (hvc)
I see a lot of hvc and smc calls from hvloader.dll in Ghidra however Windows does not provide public symbols for hvloader.dll, which complicate its reverse engineering .
UEFI firmware
Edit: A good starting point would be to dump the content of the exception tables in EL3 and EL2. However this can not be done from EL1 because VBAR_EL2,3 can't be accessed from EL1. I will see if this can be extracted from a UEFI firmware update and analyze them offline
Feel free to open a new issue for that! Unfortunately, this is something I know practically nothing about. But having KVM support would be awesome.
Thanks for your contribution to making Linux usable on SPX.
I have no experience in making Adreno GPU work in Linux, can you provide more detailed steps to guide us.
Currently, I installed the xf86-video-freedreno package in Arch Linux ARM and face a problem:
Xorg.0.log:
NO msm DRM/KMS, fallingback to fbdev/kgsl
GUI can show up without freedreno -> no GPU acceleration.
The kernel was compiled using spx/next-20220607 branch/ and boot up with DT.
Can you post a full dmesg log? Also what's the putput of ls -l /sys/class/drm?
In terms of user-space software, I only explicitly installed mesa (next to gnome on Arch, which may have pulled in some other dependencies). I haven't tried with xorg yet (only Wayland), but that shouldn't really make a difference.
There are no files under /sys/class/drm directory. My SPX cannot connect to the internet via a USB ethernet port, that's a bit hard to post the log. I will try to use mesa driver to see if anything will work.
In that case, I don't think mesa will work either. Does /sys/bus/platform/devices/2c00000.gpu exist?
Okay, so might be a difference between SQ1 and SQ2. What about cat /sys/kernel/debug/devices_deferred?
That means that no devices (that have drivers) wait on other drivers to load. I can't seem to find any reference to pretty much anything GPU related in your dmesg log. Can you post your kernel config?
Can you try and export the final/actual config with zcat /proc/config.gz > config or something like that? There seem to be a bunch of other devices missing as well... at the very least SAM.
Okay, so the config checks out... it kinda looks like everything with drivers built as modules doesn't work... Can you check if they're accessible (e.g. run modinfo msm or something like that).
So I guess it can't find any modules... the partitions are mounted properly? What about ls -l /usr/lib/modules/<your-kernel-version>?
total 24
-rw-r--r-- 1 root root 45 Jun 12 2022 modules.alias
-rw-r--r-- 1 root root 12 Jun 12 2022 modules.alias.bin
-rw-r--r-- 1 root root 0 Jun 12 2022 modules.builtin.alias.bin
-rw-r--r-- 1 root root 0 Jun 12 2022 modules.builtin.bin
-rw-r--r-- 1 root root 0 Jun 12 2022 modules.dep
-rw-r--r-- 1 root root 12 Jun 12 2022 modules.dep.bin
-rw-r--r-- 1 root root 0 Jun 12 2022 modules.devname
-rw-r--r-- 1 root root 55 Jun 12 2022 modules.softdep
-rw-r--r-- 1 root root 49 Jun 12 2022 modules.symbols
-rw-r--r-- 1 root root 12 Jun 12 2022 modules.symbols.bin
Okay, there should be a kernel directory with modules there... So I guess either something isn't mounted properly or whatever you used for installation missed some parts.
Okay, there should be a
kerneldirectory with modules there... So I guess either something isn't mounted properly or whatever you used for installation missed some parts.
Thanks for the hint. I will look into it.
Solved. copymods was mounted under /lib/modules, all kernel modules will be deleted after reboot. SAM and GPU works on SQ1
I got some problems while booting Fedora 36 installation on my surface pro x.
First, I downloaded fedora image for aarch64 on its website. And then I build linux kernel from linux-surface/kernel:spx/v5.19-rc8 with its dtbs, using config full/spx-5.19.rc1-fedora_36.config from qzed/aarch64-kernel-configs. Afterwards, I replace the original vmlinuz with built file arch/arm64/boot/Image.gz and edit grub.cfg. However, I failed to boot after loading initrd.
Here is my grub.cfg:
set default="1"
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2
set timeout=60
### END /etc/grub.d/00_header ###
search --no-floppy --set=root -l 'Fedora-WS-Live-36-1-5'
### BEGIN /etc/grub.d/10_linux ###
menuentry 'Start Fedora-Workstation-Live 36' --class red --class gnu-linux --class gnu --class os {
echo "Loading DTB..."
devicetree /images/pxeboot/sc8180x-surface-pro-x.dtb
echo "Loading kernel.."
linux /images/pxeboot/vmlinuz clk_ignore_unused root=live:CDLABEL=FEDORA-WS-L rd.live.image quiet rhgb efi=novamap
echo "Loading initrd..."
initrd /images/pxeboot/initrd.img
}
menuentry 'Test this media & start Fedora-Workstation-Live 36' --class red --class gnu-linux --class gnu --class os {
echo "Loading DTB..."
devicetree /images/pxeboot/sc8180x-surface-pro-x.dtb
echo "Loading kernel.."
linux /images/pxeboot/vmlinuz clk_ignore_unused root=live:CDLABEL=FEDORA-WS-L rd.live.image rd.live.check quiet efi=novamap
echo "Loading initrd..."
initrd /images/pxeboot/initrd.img
}
submenu 'Troubleshooting -->' {
menuentry 'Install Fedora-Workstation-Live 36 in basic graphics mode' --class red --class gnu-linux --class gnu --class os {
echo "Loading DTB..."
devicetree /images/pxeboot/sc8180x-surface-pro-x.dtb
echo "Loading kernel.."
linux /images/pxeboot/vmlinuz clk_ignore_unused root=live:CDLABEL=FEDORA-WS-L rd.live.image nomodeset quiet rhgb efi=novamap
echo "Loading initrd..."
initrd /images/pxeboot/initrd.img
}
}
I'm a beginner in linux kernel field, would you please lend me a hand?
Em, it seems that I've found a corresponding explanation in https://github.com/linux-surface/grub/issues/1
I've recently gotten ahold of a windows dev kit 2023, which appears to be a surface pro 9 (5g) / sq3 in a box, and I'm attempting to boot linux on it with these patches.
Progress so far -
- Booting base Ubuntu 22.04.1 LTS arm image - Hangs at:
Booting a command list
Synchronous Exception at 0x0000000C1B17927C
- Building a "default" profile image with the image tool - Hangs at:
Loading initramfs...
Booting into Surface kernel...
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services...
Barring better suggestions, I'm going to try to extract the firmware with the script from aarch64-firmware and stuff it into the arch image above and see where that gets booting
-
could possibly be fixed by https://github.com/linux-surface/grub/commit/55b95a388414a3d850e24fd2ae8fac100ffd9319. So you could try to use e.g. the pre-built grub from https://github.com/linux-surface/grub-image-aarch64/releases/tag/fedora-37-2 with your Ubuntu kernel. Alternatively, just use the image from 2) which contains the patched grub, but remove the
devicetreeoption from the boot entry. That should get you booting in ACPI mode. -
is way before any firmware gets loaded, so I doubt that that will make any difference. Can you make sure that
efi=novamapis set (pressein the grub menu to edit)? Also, this is booting with the SPX DT, and I'm not sure if that's a good idea. So as I've said above, you can remove thedevicetreeoption in the grub config and it should hopefully get you a bit further.
You can also experiment with earlycon=efifb.
In the long run, you'll probably want to have a look at the DT of the sc8280xp (that is 8cx Gen 3; it's also used in the Thinkpad X13s) and use that as a base. Also, you might want to join the oftc/#aarch64-laptops IRC. There are a lot more experienced people who also might have some ideas.
For the dev-kit see #43. As far as I understand, it's booting via ACPI with display support, but a DT will likely be required to get the GPU working.
For the SPX: I'm a bit busy right now, so progress is somewhat slow. I'm working on getting some patches for UEFI variables (that are also useful for other Qualcomm devices) upstream. I'll also need to revisit the GRUB patches (completely forgot about those). So hopefully I can find the time to work on that over easter.
There's also https://github.com/linux-surface/aarch64-arch-mkimg/pull/5 to build a DT-bootable disk image that should hopefully make installation a bit easier. Unfortunately, that seems to building somewhat randomly (fails downloading a package from our repo) and I'm not exactly sure why.
Hey, I think it's really great to see progress like the arm64 releases, but is there any progress on the audio or webcam drivers?
@TimoRams Not on the SPX side, unfortunately.
I'm not sure how far along webcam support is on the X13s (that could probably at least partially be adapted for the ARM-based SP9 and DevKit). AFAIK audio should work on that though (but again might have to be adapted in some parts, at least integrated in some DTS).