Status

[Sonicadvance1]

Device Status

Booting with ACPI:

• All eight CPU cores
  • Clock Scaling
• Application Processor MMU
• Adreno MMU
• Left USB ports
• Display
• Right Surface Connect port
• Keyboard cover (SAM)
• Audio
• Adreno
• Wifi
• Thermal Zones
• Modem
• Display brightness control
• NVMe drive
• Touchscreen

Booting with Device Tree:

• All eight CPU cores
  • Clock Scaling
• Application Processor MMU
• Display
• Adreno MMU
• Left USB ports
• Right Surface Connect port
• Keyboard cover (SAM)
• Audio
• Adreno
• Wifi
• Thermal Zones
• Modem
• Display brightness control
• NVMe drive
• Touchscreen

[Sonicadvance1]

https://twitter.com/Sonicadvance1/status/1199894673013137408
This is the device booting, but it is with ACPI boot and has severe limitations.
ACPI isn't really desired for ARM devices under Linux (I don't believe Freedreno even supports ACPI booting devices), so Device Tree needs to be generated.

[Dmole]

Might be worth asking the kernel contributors with Microsoft/Qualcomm emails for help.

git log --format=fuller | grep -P '@(microsoft|.*qualcomm)' | perl -pe 's/.*<|>//g' | grep -v " " | sort | uniq -c | sort -rn | grep -P '\d{3} '
   5212 kvalo@qca.qualcomm.com
   3012 kys@microsoft.com
   1774 haiyangz@microsoft.com
   1697 stfrench@microsoft.com
   1245 c_manoha@qca.qualcomm.com
    929 hjanssen@microsoft.com
    634 mawilcox@microsoft.com
    613 qca_vkondrat@qca.qualcomm.com
    536 sthemmin@microsoft.com
    469 rmanohar@qca.qualcomm.com
    450 pshilov@microsoft.com
    402 decui@microsoft.com
    396 v-abkane@microsoft.com
    390 james.morris@microsoft.com
    347 vthiagar@qca.qualcomm.com
    297 mohammed@qca.qualcomm.com
    284 jouni@qca.qualcomm.com
    280 rmanohar@qti.qualcomm.com
    264 longli@microsoft.com
    259 mikelley@microsoft.com
    184 qca_merez@qca.qualcomm.com
    144 mcgrof@qca.qualcomm.com
    134 mohammed@qti.qualcomm.com
    106 rmani@qti.qualcomm.com
    101 vthiagar@qti.qualcomm.com

[lkocman]

Hello @Sonicadvance1 how did you get the system to the internal storage? Install image on a USB pen drive, or did you write image/system to the internal storage directly?

I'm just trying to get TW aarch64 image booting from a pen drive, so far it's not being recognized when I choose to boot from USB drive in the Surface/UEFI menu.

I did buy a usb c reader for the internal drive, but unfortunately it seems to be broken, so I'm stuck with pendrive.

I must say that the option to easily swap disks and have one installation WIP is a big plus in otherwise hostile environment :-)

[lkocman]

My experience with booting a USB install image:

I've tried to boot from The advanced recovery options, however that messed up the underlying windows installation and generally always took longer as it asks me for a bitlocker recovery key.

Bitlocker drive encryption can be turned off from Windows. Control Panel -> System and Security -> BitLocker Drive Encryption -> Turn off Bitlocker (Triggers disk decryption on background).

If you go to Surface UEFI - > Boot Configuration and simply swipe left, then the entire cycle takes few seconds.
I did turn of the secure boot, however I didn't yet get to the point where it would make the difference.

My setup is a usb-c connected dell docking station with 1GB SandDisk USB-3.0 flash drive with latest openSUSE TW aarch64 image connected to the docking station. I'm using usb based mouse+keyboard connected to the dock and they both work well in the Surface UEFI area.

I didn't get the usb pen drive with aarch64 openSUSE TW booting via docking station, but I suppose it's because the was simply not recognized. Next step is to try usb-c pendrive directly connected to the surface device. That will have to wait until mid of next week as shops are closed on Sunday and I'll be travelling Monday/Tuesday.

So current goal is to get grub2 screen, next goal is to get kernel loaded.

[lkocman]

Just for keeping track of progress

So default openSUSE Tumbleweed aarch64 image on a usb-c flash disk plugged directly to surface boots (Volume Up+ power button -> Surface UEFI -> Boot from USB) for about 3 seconds and freezes on following
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual adress map...

[lkocman]

I'm now trying to build openSUSE Tumbleweed minimal CD with a kernel patch from Ryan
https://build.opensuse.org/project/show/home:lkocman:aarch64-laptops

My 5.8 based-branch where I'll add individual changes from Ryan and hopefully later some more
https://github.com/lkocman/linux/tree/wip/sq1_surface_prox
Patched kernel will be then built here https://build.opensuse.org/package/show/home:lkocman:aarch64-laptops/kernel-source

[RussianNeuroMancer]

I'm now trying to build openSUSE Tumbleweed minimal CD with a kernel patch from Ryan

Does it help?

[kachapman]

Has there been any improvement to device functionality since the Dec post last year?

[lewurm]

Leaving this as a reference: Patches to support the embedded controller in Surface devices are about to be upstreamed: https://lkml.org/lkml/2020/9/23/535

This should help to get the keyboard cover working (if not more).

[Dmole]

This should help

The Surface Pro X is, however, currently considered unsupported due
to a lack of test candidates and, as it seems, general lack of
Linux support on other parts. AFAIK there is an issue preventing
serial devices from being registered, on which the core driver in
this series is build on, thus there is no way to even test that at
this point. I'd be happy to work out any issues regarding SAM on
the Pro X at some point in the future, provided someone can/wants
to actually test it.

[qzed]

My information for the comment above comes from #7 (comment). If that still holds true, i.e. if the Surface Serial Hub (SSH/MSHW0084) device still is not present, the SAM modules won't load. SSH is basically the interface to the EC. Also it's a UART, if that matters (essentially handled via the serdev interface, should show up at /sys/bus/serial/devices).

Also if anyone has access to an acpidump/DSDT, can you post one to https://github.com/linux-surface/acpidumps (see here for more details)? I'd love to have a look at it, although I'm not sure I can do much about it if the UART device doesn't show up.

Regarding there being no keyboard "device": Are you sure it's connected via SAM (if so, how?). If it is, we'll have to figure out what interface it's using. Likely the updated HID interface, but we'll have to confirm that and manually add the device. Also we'll need to figure out how detachment is handled (i.e. are there any GPIOs that signal this?) and if we have to take care of that ourselves (which is quite likely).

Edit: Feel free to report back at linux-surface/surface-aggregator-module#53.