Status

[Sonicadvance1]

trafficstars

Device Status

Booting with ACPI:

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

Booting with Device Tree:

• [x] All eight CPU cores
  • [ ] Clock Scaling
• [x] Application Processor MMU
• [x] 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 [email protected]
   3012 [email protected]
   1774 [email protected]
   1697 [email protected]
   1245 [email protected]
    929 [email protected]
    634 [email protected]
    613 [email protected]
    536 [email protected]
    469 [email protected]
    450 [email protected]
    402 [email protected]
    396 [email protected]
    390 [email protected]
    347 [email protected]
    297 [email protected]
    284 [email protected]
    280 [email protected]
    264 [email protected]
    259 [email protected]
    184 [email protected]
    144 [email protected]
    134 [email protected]
    106 [email protected]
    101 [email protected]

[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 https://github.com/Sonicadvance1/linux/issues/7#issuecomment-559641767. 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 https://github.com/linux-surface/surface-aggregator-module/issues/53.

[RussianNeuroMancer]

Also if anyone has access to an acpidump/DSDT,

You can take it here: https://github.com/aarch64-laptops/build/tree/master/misc/microsoft-surface-prox

[qzed]

Thanks. According to the DSDT the underlying UART has HID QCOM0418. I can't seem to find any driver for that upstream, so could be that it's missing one (or at least an ACPI version for it). If so, you'll have to fix that first (or, of course, describe everything with DTs, but then you'll also have to adapt the SSH driver to load as that currently only supports ACPI, shouldn't be a huge change though).

Also, depending on the kernel version (and if you decide to use ACPI) you may need to back-port https://github.com/torvalds/linux/commit/33364d63c75d6182fa369cea80315cf1bb0ee38e (required for the SSH device to be created) and https://github.com/torvalds/linux/commit/6d232b29cfce65961db4a668c2c6c6987cd24d45 (required for the SAN device to behave properly).

[thmichel]

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...

Same here. Downloaded the latest iso from the OpenSuse build server.

[denysvitali]

Uhm, same here, stuck at:

EFI stub: Exiting boot services and installing virtual adress map...

I've tried with a modified kernel using this patch: https://github.com/Sonicadvance1/linux/commit/b1fc9ae517cc12d9f02ebf2c732e008f07ac988a

but it still stuck there.

I'm using a Surface Pro X SQ2 and I'm manually booting the kernel via GRUB (any tip on how to speed up the kernel trial and errors would be great!)

[denysvitali]

I would also like to point out that @lkocman 's iso image (OpenSUSE ISO) has the exact same problem: stuck at EFI stub: Exiting boot services and installing virtual address map....

I'm not sure if there might be a huge difference between SQ1 and SQ2 that may require a different patch... :thinking:

Can someone with a SPX SQ1 check if the above mentioned iso gets stuck as well?

Here is a mega.co.nz mirror of that image, since it is built every night: https://mega.nz/file/xuB1QaLC#j--JPwNDFVSOHYtiUPZ0vWsVHDQHsKJ5omBxBdTPuwA

SHA256:

dba6a104e21a144aa7de89048d53bf2f57a6f9b740ae32725ac6924f145d4e9d  openSUSE-Tumbleweed-NET-aarch64-Build4.71-Media.iso

[denysvitali]

Apparently it gets stuck here after update_fdt:

[denysvitali]

Status update: after applying the patch again, it doesn't get stuck anymore at the efi_exit_boot_services anymore. The kernel panics though and thus the device restarts as soon as the kernel loads (the penguins are visible for a couple of ms)

[denysvitali]

Okay, so for some strange reason the https://github.com/Sonicadvance1/linux/commit/b1fc9ae517cc12d9f02ebf2c732e008f07ac988a patch doesn't work, but mine (with the debugging information) https://github.com/denysvitali/surface-pro-x-linux/commit/44944273f4fc43eb497326886573918a6abebee3 does.

Could it be maybe related to some delay that we have to add? In any case, I can't seem to get past a quick three penguins screen (that is shown very distorted for < 20ms) and a reboot that happens after the penguins disappear and after ~ 6 seconds have elapsed. I feel like the kernel is booting but the display is not correctly initialized. I'm now trying to force the screen to not take over and keep the fbcon.

---

No luck with nomodeset and vga=0 :(

[klardotsh]

Sorry to jump in if you've already tried this, but do you by chance get more context with earlycon=efifb? I think earlycon might be gone by the time you see Tuxen but it's worth a shot perhaps (my C630 would spit out useful debugging context with that when I was testing kernel builds)

[denysvitali]

Thanks Josh for your help! This indeed has helped me understand better what happens. The kernel starts (duh!) but anything past the earlyprintk is basically hidden. I think that the display might get initialized and thus the console output is hidden since I can clearly see the display becoming black for 5 seconds. Then the device reboots.

I guess that underneath the kernel does indeed start, but then it panics somewhere. Without a tty it is really difficult to see what's going on: maybe a look at the DT might help me somehow

[denysvitali]

Okay, another status update, booting with earlycon=efifb console=efifb gives waay more output and shows where the screen gets blank (I had to take a video). I can spot some ACPI and firmware errors, but I don't think they're relevant for a successful boot. What happens is that after this last line (related to SMMU), the screen goes black and the device restarts after ~5 seconds.

Here is a picture of the kernel messages right before the screen goes black:

[denysvitali]

Okay, silly me, I wasn't using any dtb when booting 🤦‍♂️

It now kind of works (no reboot) and the penguins are shown correctly, with a nice kernel log output on screen that unfortunately gets stuck after a while.

My setup:

• USB-C HUB (HooToo, as used in my linux-pixelc project)
• 64 GB SD Card
• 16 GB USB drive

On the 64 GB SD Card I keep an iso of Ubuntu 20.04 Server for aarch64, and since iso images aren't that easy to edit, I use an external USB drive to quickly put new kernel images and other useful files that I later on load with GRUB using the partition name (in my case (hd1,msdos1))

My GRUB entry is:

devicetree (hd1,msdos1)/prox_sc8180.dtb
linux (hd1,msdos1)/Image
initrd /casper/initrd

[denysvitali]

I've tried the ACPI way (extracting the ACPI tables from Windows and using them when compiling the kernel), but unfortunately I don't get anything more than a boot that is stuck at the EFI messages

[denysvitali]

@mirh suggested me that this patch might be helpful: https://gitlab.freedesktop.org/drm/msm/-/commit/aded8c7c2b72f846a07a2c736b8e75bb8cf50a87

I'll look into it ASAP

---

Nevermind, that patch is already in the kernel I'm using, therefore it is not needed and doesn't fix the boot problem :(

[denysvitali]

I now get a kernel panic, despite I have made little to no edits to my kernel: could it be that the efifb doesn't always display the kernel panic stack tace?

[maor26]

Maybe you can try and ask in #aarch64-laptops on irc.freenode.net . There's a repo that lists a few snapdragon devices with what works and what doesn't on linux : https://github.com/aarch64-laptops/build But as I understand, it's a little out of date and you're better off asking in #aarch64-laptops.

[denysvitali]

Just for the record: this is what happens usually: https://youtu.be/WW9FU6IClvI

[denysvitali]

My good friend @mirh just found this: https://github.com/andersson/kernel/tree/wip/sc8180x-next-20201111

I'm so excited and I'll give it a try ASAP!

[denysvitali]

Okay, booting that doesn't reboot the tablet and doesn't get it stuck, but the USB doesn't work (probably I didn't describe it correctly in the DT).

Booting via ACPI doesn't really help either: is maybe the SPX USB connected to the SSH, and that's maybe why it doesn't appear there?

Ideally to test it out I can try to boot from the internal mmcblk, but so far I've only tested USB booting