linux-surface
linux-surface copied to clipboard
jakeday
Surface Pro 7 (2019)
Can we add to the script the Surface Pro 7 so I can give jakeday a try on it when it comes out? Should be reasonably similar to the pro 6 in terms of hardware...
You should use the updated setup script from qzeds repository: https://github.com/qzed/linux-surface
The script had to check for the device names because IPTS (the touchscreen driver) didn't support multiple firmwares installed in parallel. This has changed, so the script doesn't check for the names anymore (except for some device-specific fixups)
Thank you for clarifying this. Then why use the qzed repo instead of jakeday? If jakeday script doesn't check for names, can I use jakeday as usual? Will try an install on a surface pro 7 with arch in a couple of days.
18.04 would not install on my surface. It wouldn't even boot the installer. I put 16.04 on my new surface 7. "No wifi adapter found" and bluetooth won't turn on. With several reboots I finally got my anker usb Ethernet to work. I tried several "fixes" for wifi, none worked. So I updated to 18.04. Nothing changed. i've run jakeday on it (qzed is cloning jakedays repo) and it fails to boot. The last line seems to be looking for a policy file 31. Booting back to previous kernel works fine. Will update if/when I get it working
@chester681 I don't know if it helps, but apparently the SP7 uses an intel wireless chip as opposed to previous generations that used a marvell chip.
@chester681 Can you upload an acpidump and lspci/lsusb output? Also some infos on what's going wrong during boot would help (eg via journalctl -b -1, which kernel exactly?).
I've just become aware of the change to Intel Wifi. I'm currently upgrading to 19.04 just to see if it will work out of the box. If not, a fresh install of 16.04 again
The kernal that wont boot is 5.1.15-surface-linux-surface. With the following error
FWIW: i see an error about the system time: I chose "yes" about adjusting the system clock when running the jakeday script
18.04 and 19.04 won't boot from USB. Saying soemthing like "Not all CPU's entered broadcast"
@chester681 Can you upload an acpidump and lspci/lsusb output? Also some infos on what's going wrong during boot would help (eg via
journalctl -b -1, which kernel exactly?).
chester@chester-Surface-Pro-7:~$ lspci 00:00.0 Host bridge: Intel Corporation Device 8a12 (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Device 8a52 (rev 07) 00:04.0 Signal processing controller: Intel Corporation Device 8a03 (rev 03) 00:05.0 Multimedia controller: Intel Corporation Device 8a19 (rev 03) 00:0d.0 USB controller: Intel Corporation Device 8a13 (rev 03) 00:12.0 Serial controller: Intel Corporation Device 34fc (rev 30) 00:14.0 USB controller: Intel Corporation Ice Lake-LP USB 3.1 xHCI Host Controller (rev 30) 00:14.2 RAM memory: Intel Corporation Device 34ef (rev 30) 00:14.3 Network controller: Intel Corporation Device 34f0 (rev 30) 00:15.0 Serial bus controller [0c80]: Intel Corporation Ice Lake-LP Serial IO I2C Controller #0 (rev 30) 00:15.2 Serial bus controller [0c80]: Intel Corporation Ice Lake-LP Serial IO I2C Controller #2 (rev 30) 00:15.3 Serial bus controller [0c80]: Intel Corporation Ice Lake-LP Serial IO I2C Controller #3 (rev 30) 00:16.0 Communication controller: Intel Corporation Device 34e0 (rev 30) 00:16.4 Communication controller: Intel Corporation Device 34e4 (rev 30) 00:19.0 Serial bus controller [0c80]: Intel Corporation Ice Lake-LP Serial IO I2c Controller #4 (rev 30) 00:1d.0 PCI bridge: Intel Corporation Ice Lake-LP PCI Express Root Port #9 (rev 30) 00:1e.0 Communication controller: Intel Corporation Ice Lake-LP Serial IO UART Controller #0 (rev 30) 00:1f.0 ISA bridge: Intel Corporation Ice Lake-LP LPC Controller (rev 30) 00:1f.3 Audio device: Intel Corporation Device 34c8 (rev 30) 00:1f.5 Serial bus controller [0c80]: Intel Corporation Ice Lake-LP SPI Controller (rev 30) 01:00.0 Non-Volatile memory controller: SK hynix Device 1327 chester@chester-Surface-Pro-7:~$ lsusb Bus 004 Device 003: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter Bus 004 Device 002: ID 2109:0812 VIA Labs, Inc. VL812 Hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 002: ID 045e:09c0 Microsoft Corp. Surface Type Cover Bus 003 Device 004: ID 2109:2812 VIA Labs, Inc. VL812 Hub Bus 003 Device 003: ID 8087:0026 Intel Corp. Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
For 5.1: The TPM error should not cause the system to fail booting and should be fixed on 5.2 and 5.3 (I think). So it looks like this is an SELinux issue. Have you tried (temporarily) disabling that (see e.g. https://access.redhat.com/solutions/91863)?
For 18.04 and 19.04: Can you make sure that the microcode of your CPU is up to date?
For 5.1: The TPM error should not cause the system to fail booting and should be fixed on 5.2 and 5.3 (I think). So it looks like this is an SELinux issue. Have you tried (temporarily) disabling that (see e.g. https://access.redhat.com/solutions/91863)?
For 18.04 and 19.04: Can you make sure that the microcode of your CPU is up to date?
I'm not sure what to do with this information. I'd never heard of microcode and a quick search seems to indidicate this is how to check mine grep name /proc/cpuinfo | sort -u model name : Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz
I havent tried to disable SEL. My 19.04 upgrade is complete. Rebooting into it now.
@chester681
I have been able to get Linux booting, with an added parameter noapic. The hang seems to be caused by intel-lpss.
Weirdly, however, I was only able to observe the Kernel Panic with Ubuntu 19.10, but not with Arch Linux or AOSC OS. All these distributions have Kernel 5.3.
I am currently poking around to collect some issues - and there are indeed quite a few. However, I am currently running the upstream Kernel, but will try out some patches from @qzed later.
I think I will post a new issue as a sort of "situation report".
Rebooting into 19.04 upgrade gave me the kernel panic: Not all CPU broadcasting. Note: the 18.04 USB did this too, but upgrading to 18.04 from 16.04 did not.
Rolling back now to a fresh 16.04 Install. Then to try looking for some Intel drivers for Wifi and Bluetooth. Will update later this afternoon if anything changes
message on reboot after 16.04 install. This explains the bluetooth not working, at a minimum
Hey man. Just installed latest arch on my surface pro 7 (core i7 model)
Wifi works out of the box and jakeday kernel 5.3.6 seems ok (still figuring out battery).
The problem you mentioned of the installer hanging up is due to the processor, just pass this kernel parameter when the live USB boot:
Modprobe.blacklist=Intel_Lpss_Pci
(All lowercase, sorry as I'm typing this on a phone).
You Can find out more if you Google i7-1065-g7 and Linux kernel parameters.
No need to use an adapter. Also, wifi works well with linux-firmware stock drivers and iwlwifi Intel drivers.
More about the arch installer hanging and how I solved it: https://www.reddit.com/r/archlinux/comments/dls68s/live_usb_installer_stuck_here_any_ideas/?utm_medium=android_app&utm_source=share
Just read you are using Ubuntu, pass the same parameter to the ubuntu installer (press e when the live grub loads). For arch, we have latest kernel patched for surface, 5.3.6. If Ubuntu has 5.1.5 I'm not use e but it should work too. Remember to pass the same parameter in your loader entries after installation, or boot will hang again.
@aleksfadini Can confirm that your parameter is working as a workaround.
Hey man. Just installed latest arch on my surface pro 7 (core i7 model)
Wifi works out of the box and jakeday kernel 5.3.6 seems ok (still figuring out battery).
The problem you mentioned of the installer hanging up is due to the processor, just pass this kernel parameter when the live USB boot:
Modprobe.blacklist=Intel_Lpss_Pci
(All lowercase, sorry as I'm typing this on a phone).
You Can find out more if you Google i7-1065-g7 and Linux kernel parameters.
No need to use an adapter. Also, wifi works well with linux-firmware stock drivers and iwlwifi Intel drivers.
I can also confirm your blacklist param allowed me to boot the jakeday 5.1.15 kernel. Still no wifi or bluetooth. Did you install the Intel drivers or were they included with arch?
For wifi to work install the arch package linux-firmware, works out of the box. Of course, installing a package without wifi can be tricky; one way to do it is to arch-chroot from the live usb, which has wifi working on the SP7. edit: also, if you are on arch, you can install jakeday 5.3.6 from this custom repo: https://github.com/qzed/linux-surface/wiki/Package-Repositories#arch-linux-repository edit2: I saw you are using ubuntu. Not sure how to help there. These are standards iwlwifi Intel drivers.
I've got the Wifi and Bluetooth working on Ubuntu 16.04 with by using the latest linux-firmware files.
However, I cannot get the touchscreen working, even with the new patch on intel-lpss-pci : https://github.com/qzed/linux-surface-kernel/pull/13 I compiled the last version of https://github.com/qzed/linux-surface-kernel, and the intel_lpss_pci module loads, but it doesn't help. I also copied all the i915 files of the last linux-firmware.
The dmesg.txt shows multiple stacktrace involving i915, but I don't know if they are relevant to the touch screen.
That's great! In order to help fixing the touchscreen, if you have windows, could you do what is required here by qzed:
Unfortunately, I2C devices are difficult to identify. There's no mechanism built into the specification as for example on USB or PCIe. You'd likely have to look around on Windows if you can find anything there. A good place to start would be the device manager. You could try to look for the device by its connection (View->Devices by connection) and figure out its "BIOS device name" property, if it has one (right click -> properties -> details -> search for the entry in the drop-down menu). Also other stuff like which driver it uses.
And follow up posting your touchscreen info and the driver that window uses on this thread: https://github.com/qzed/linux-surfacegen5-acpi/issues/21
So qzed can maybe give it a shot? We might have a chance! Thank you. Other than that SP7 works well, I just do not have battery or touchscreen.
Adding modprobe.blacklist=intel_lpss_pci I managed to boot TailsOS on MS SurfacePro 7 (i7). But I have the same issues as above: no touchscreen and worse: no indication about battery status. If anyone has some advice about the battery issue I would appreciate
I have made the battery/AC sensors working on Surface Pro 7 with a minor modification of @qzed's patch for 5.4.6 kernel. The problems stem largely from the Icelake CPU only recently gaining full support in the kernel. Below are the details:
- According to the ACPI tables, the ID for the device is MSHW0186. In the code by qzed, the Surface Pro 7 is listed under the ID of MSHW0116. So I've simply duplicated the relevant line in drivers/platform/x86/surface_sam/surface_sam_sid.c, see the attached patch surface-pro-7-sid.patch.txt. The module has to be loaded manually (or via /et/module-autoload, etc): modprobe surface_sam_sid_power(I could not figure out quickly why it is not loading itself.)
. (My machine is 8GB/256GB i5. bought in the UK, if that matters).
- It has to be kernel 5.4, though: the same trick does not work for kernel 5.3, as something is broken in this kernel re handling of pin/gpio lines on the icelake. Kernel log is spammed with messages like:
icelake-pinctrl INT3455:00: request() failed for p in 114 icelake-pinctrl INT3455:00: pin-114 (INT3455:00:354) status -16 surface_sam_ssh: probe of serial0-0 failed with error -16
This apparently has been fixed in 5.4, it is doing just fine as I am writing this.
- What's next? The next desired feature is obviously the touchscreen. @qzed's patches provide IPTS for kernels upto 5.3. I've tried this out on my device. The problem is apparent lack of this support of the guc firmware in kernel 5.3: modinfo i915 on this kernel returns the dmc firmware for icelake, but no guc or huc. (Not sure why, though: Icelake GuC 32.0.3 is mentioned in the code, but apparently is not compiled in?). The GuC firmware on Icelake (32.0.3) is supported in kernel 5.4, but apparently there is no IPTS patch adapted to this kernel. From what I could see, kernel 5.4 includes a signifiwcant reorganisation of drm/i915, so making this patch working is not entirely trivial: one has to rewrite the code that takes events from the internals of i915. I could not find any traces of this work being done. If someone is working on it, and would like to test it, I may be willing to help.
Thank you @avshytov, I will try kernel 5.4 with your patches. Now I'm using the pre-built 5.3 image of @qzed
Hi @avshytov what's your 5.4 kernel config file, there are many new configs, I choose all default options.
With @avshytov modifications and @qzed patch and 5.3 debian kernel config, I build the 5.4.6 kernel source code with default new options, and then modprobe surface_sam_sid_power, still no battery status
ls /proc/acpi/ button wakeup
Now the battery works on my Ubuntu 19.10 and Surface Pro 7 with i7 16GB 1TB
I use the original @qzed patch and 5.3 debian kernel config, build the 5.4.6 kernel source code with default new options, and then add surface_sam_sid_power to modules.conf
OK, so if the @qzed patch works unmodified on your machine, it is likely to use the same hardware ID, MSHW0116, as in the original patch.
Hi, so let's first look at the surface-acpi/surface-sam issues.
Let's go with the auto-loading first: That should be easy to fix and I'll update the patches later. It basically boils down to the driver requiring a MODULE_ALIAS for surface_sam_sid_ac and surface_sam_sid_battery, I think. I'll update this issue once the changes have been pushed, would be nice if you can check that that works then.
The ID issue may be a bit more complex: From the feedback I've gotten, MSHW0116 should be the SID device ID. The MSHW0186 does not look like it belongs to the SID device, but instead to Intel DPTF participant devices according to the acpidump that I have, so I'd like to avoid using that. If MSHW0116 doesn't work in some cases, it looks like different versions of the SP7 have different IDs.
@avshytov can you try to find out the SID device ID of your model? This is a bit of work: You have to find the platform device for which
cat /sys/bus/platform/devices/MSHWxxxx:00/firmware_node/path
returns \_SB.WSID.
For Touchscreen/IPTS on 5.4: Intel has disabled GuC submission since 5.3 (I think?) due to changes in firmware. IPTS unfortunately relies on that, so in 5.3 we have basically copied the whole i915 driver from 5.2 to 5.3. Unfortunately that's no longer feasible for 5.4. Intel plans to re-enable GuC submission, at least for gen11+ devices) at some point in the future, but gen9 devices might never get GuC submission back without some work from us.
We are currently trying to find a workaround without GuC (as we don't even seem to have the IPTS firmware for the newer devices which is required for the whole GuC processing). You might want to join our IRC channel (freenode/##linux-surface) if you're interested and want to help out or want to know more details.
Hi, so let's first look at the surface-acpi/surface-sam issues.
Let's go with the auto-loading first: That should be easy to fix and I'll update the patches later. It basically boils down to the driver requiring a MODULE_ALIAS for
surface_sam_sid_acandsurface_sam_sid_battery, I think. I'll update this issue once the changes have been pushed, would be nice if you can check that that works then.The ID issue may be a bit more complex: From the feedback I've gotten,
MSHW0116should be the SID device ID. TheMSHW0186does not look like it belongs to the SID device, but instead to Intel DPTF participant devices according to the acpidump that I have, so I'd like to avoid using that. IfMSHW0116doesn't work in some cases, it looks like different versions of the SP7 have different IDs.@avshytov can you try to find out the SID device ID of your model? This is a bit of work: You have to find the platform device for which
cat /sys/bus/platform/devices/MSHWxxxx:00/firmware_node/pathreturns
\_SB.WSID.
Tried this, and it is indeed MSHW0116, so it may be a mistake on my part. (I first tried to analyse all occurrences of MSHW in both DSDT and SSDT2, and found most IDs to be the same as in your code, except for this one. After you've told me it has to be WSID, I see that the DSDT calculates its value implicitly instead of making it hardcoded. I can provide full tables if needed, but it is indeed 0116 on my machine anyway.)
Thanks a lot for your work, it has already made the device much, much more usable in Linux.
@avshytov
After you've told me it has to be WSID, I see that the DSDT calculates its value implicitly instead of making it hardcoded.
Yeah that's a bit unfortunate, as I can't fully rely on the DSDT with stuff like that.
I can provide full tables if needed, but it is indeed 0116 on my machine anyway.
Thanks for the offer, I already have a DSDT for the SP7. And thanks for confirming. So with auto-loading fixed, I think it should work then.
Patches are updated and new kernels uploaded.
Thanks. Gave it a try, both 5.3 and 5.4. 5.3 suffers from the same pinctrl issues; battery and ac work all right in 5.4.
@avshytov Awesome, thanks! If you want to, you could try to find the patch fixing the pinctrl issues for 5.4 (I think @archseer mentioned something about that a while ago) so we could include that in 5.3, but on the other hand there's no real benefit of using 5.3 over 5.4 on the SP7. The only difference should be IPTS support, but that doesn't work on the SP7 anyways.
Yeah 5.4 landed a bunch of changes to pinctrl: on 5.3 a pin would be locked to prevent binding to it. On Ice Lake though, there's read-only locks that seem to be used very frequently (for ~70% of the pins) that are an indicator saying you can only read from the pin. 5.3 doesn't distinguish the type of lock, so it won't let you bind to the required pins, whereas on 5.4 you can bind and read from it (but not write).
For gen7 I still recommend manually building the kernel and skipping the i915_legacy patch hack. I had issues on Ice Lake because i915_legacy would bind instead of i915 and then I'd occasionally run into graphical glitches that would completely freeze up the system until I killed the session.
The i915_legacy hack isn't included in the 5.4 release, so if you want a pre-built release you probably shouldn't use 5.3 on the gen7 devices at all.