Open Sonicadvance1 opened 4 years ago
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.
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
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 :-)
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.
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...
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
I'm now trying to build openSUSE Tumbleweed minimal CD with a kernel patch from Ryan
Does it help?
Has there been any improvement to device functionality since the Dec post last year?
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).
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.
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.
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
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).
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.
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!)
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
Apparently it gets stuck here after update_fdt
:
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)
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
:(
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)
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
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:
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:
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
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
@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 :(
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?
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.
Just for the record: this is what happens usually: https://youtu.be/WW9FU6IClvI
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!
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
is maybe the SPX USB connected to the SSH, and that's maybe why it doesn't appear there?
I'd be very surprised if that's the case. Some HID devices are handled via SSH (on the Surface Laptops and Surface Book 3), so it's possible that the type-cover keyboard/touchpad are also handled by it, but USB is something that I'd expect to be handled more or less natively, if only for performance. I don't think SSH is designed/particularly well suited for large scale transfers the way some high speed USB devices are.
USB can probably be scavenged from https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/log/?h=tracking-qcomlt-sm8350-drivers https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/log/?h=tracking-qcomlt-sm8350-dts Also check the wip/lenovo-5g-next-20210119 branch.
This is the result of booting the kernel from @andersson, from the wip/lenovo-5g-next-20210119
branch, using the Lenovo Flex 5G DT:
https://www.youtube.com/watch?v=rIwSfvdSo70
The kernel doesn't panic and the device stays stuck after booting, I still think that the USB is not initialized
Rebuilding the kernel with all the modules included, despite being among the things I'm mostly not proud of, seems to have helped at least on the USB side. I now see some Qualcomm related errors (I guess they're related to the modem, which for the moment it's not necessary) and some nice logs related to usb. Unfortunately my Type C USB Hub doesn't seem to work (the devices atrached aren't recognized).
@denysvitali if it helps, I couldn't get Linux 5.11 boot on Lenovo Yoga C630 WOS with exactly same errors (yet 5.9 works just fine). @bm16ton mentioned these errors happen because some modules should be built-in, but I couldn't figure out which modules it should be. You could check build config in his GitHub (although it's for sdm845, not sc8180x) which works for him, as he said. You also could ask about these errors on aarch64-laptops mail-list or maybe just contact Bjorn directly.
yeah i cant check atm but im pretty sure their is a commit in my log just for that. it required one driver to load before the other or usb wouldnt get what was it power management i think..this change coincidently killled my i2c-hid and i had to change tgat from module to built-in or vise versa, i have no idea how they are connected. when i get a min ill check my commits
On Fri, Feb 5, 2021, 1:20 AM RussianNeuroMancer notifications@github.com wrote:
@denysvitali https://github.com/denysvitali if it helps, I couldn't get Linux 5.11 boot on Lenovo Yoga C630 WOS with exactly same errors (yet 5.9 works just fine). @bm16ton https://github.com/bm16ton mentioned these errors happen because some modules should be built-in, but I couldn't figure out which modules it should be. You could check build config in his GitHub (although it's for sdm845, not sc8180x) which works for him, as he said. You also could ask about these errors on aarch64-laptops mail-list or maybe just contact Bjorn directly.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Sonicadvance1/linux/issues/27#issuecomment-773819954, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAWMP5ZRCQQNFTGA5Y276DS5OE3XANCNFSM4J6255MQ .
Hey @bm16ton: I've tried your config without success. It would be awesome if you can find the patch you're mentioning: I can't seem to find it in your kernel source unfortunately
i didnt get tonsee the first half of this convo is the issue urbhaving the usb/intrrconnect one? if u have time may be worth compiling my source directlynand making sure it works too. if u can send me your error msg
On Fri, Feb 5, 2021, 6:09 PM Denys Vitali notifications@github.com wrote:
Hey @bm16ton https://github.com/bm16ton: I've tried your config without success. It would be awesome if you can find the patch you're mentioning: I can't seem to find it in your kernel source unfortunately
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Sonicadvance1/linux/issues/27#issuecomment-774336809, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAWMP56ISV47VQLAEWKO3TS5R3C5ANCNFSM4J6255MQ .
@RussianNeuroMancer Unfortunately neither 5.9 nor @bm16ton's kernel works for me :(
I've seen these changes though: https://lkml.org/lkml/2021/2/22/829 https://lkml.org/lkml/2021/2/22/1234
so you compile my kernel source with my config 16ton_defconfig and it didnt work? can i see the logs?
On Tue, Feb 23, 2021, 6:05 PM Denys Vitali notifications@github.com wrote:
@RussianNeuroMancer https://github.com/RussianNeuroMancer Unfortunately neither 5.9 nor @bm16ton https://github.com/bm16ton's kernel works for me :(
I've seen this though: https://lkml.org/lkml/2021/2/22/829
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Sonicadvance1/linux/issues/27#issuecomment-784576520, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAWMP3KF2F3W3KOJW3BFJ3TAQYCJANCNFSM4J6255MQ .
@bm16ton just to be sure you understand context of the conversation. @denysvitali trying to get Microsoft Surface Pro X running (it's based on Snapdragon 8cx). You know that sc8180 is different sdm845/850, right? Your config doesn't include anything for sc8180 as I can see.
Could you please clarify how you avoid this error on 5.10/5.11? https://github.com/Sonicadvance1/linux/issues/27#issuecomment-773661107 Which modules should be set to y to avoid it? That could be more useful, if it's can be applied to sc8180.
ah admitedly ive been on the road the couple times i got these emails and didnt do my do diligence on reading the thread. Still would need to see those logs tho, maybe entirely different issue. As i recall the usb issue in sdm850 was usb drivers would load before interconnect they would stahl and not recover. Is that the error hes getting. i assume theres a link in ome of these emails to the thread. ill look.
On Wed, Feb 24, 2021, 12:57 AM RussianNeuroMancer notifications@github.com wrote:
@bm16ton https://github.com/bm16ton just to be sure you understand context of the conversation. @denysvitali https://github.com/denysvitali trying to get Microsoft Surface Pro X running (it's based on Snapdragon 8cx). You know that sc8180 is different sdm845/850, right? Your config doesn't include anything for sc8180 as I can see.
Could you please clarify how you avoid this error on 5.10/5.11? #27 (comment) https://github.com/Sonicadvance1/linux/issues/27#issuecomment-773661107 Which modules should be set to y to avoid it? That could be more useful, if it's can be applied to sc8180.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Sonicadvance1/linux/issues/27#issuecomment-784803643, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAWMP7YGBSJX35D7UZUIFTTASIN5ANCNFSM4J6255MQ .
After updating my kernel to v5.11-rc7, applying some patches (clk + pinctrl) and using the Surface Pro X DTS I'm able to get some more meaningful kernel messages that now suggest something is wrong with the storage (UFS, ufshcd-qcom
).
From the pics, looks like the storage is timing out during initialization. Not familiar with the hardware or errors but id look at "invalid ufs version" it maybe a red herring but since it looks like the ufs is the issue...Is the firmware for your remote procs not available yet? The usb sees ur webcam, ur ftdi usb serial adapter etc so all looks good as far as i can see in that pic for usb. But def the ufs and i2c timing out is the place to start. i have a vague memory of devicetree patches to reset the ufs during initialization. Worth looking into what issues that fixed. ill see if i can find it.
On Fri, Feb 5, 2021, 1:20 AM RussianNeuroMancer notifications@github.com wrote:
@denysvitali https://github.com/denysvitali if it helps, I couldn't get Linux 5.11 boot on Lenovo Yoga C630 WOS with exactly same errors (yet 5.9 works just fine). @bm16ton https://github.com/bm16ton mentioned these errors happen because some modules should be built-in, but I couldn't figure out which modules it should be. You could check build config in his GitHub (although it's for sdm845, not sc8180x) which works for him, as he said. You also could ask about these errors on aarch64-laptops mail-list or maybe just contact Bjorn directly.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Sonicadvance1/linux/issues/27#issuecomment-773819954, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAWMP5ZRCQQNFTGA5Y276DS5OE3XANCNFSM4J6255MQ .
This could be interesting (despite it's for ACPI): https://patches.linaro.org/patch/388626/
Together with: https://patches.linaro.org/patch/388625/
Soo, a couple of things to get you up to speed as well:
RTL8153 Gigabit Ethernet Adapter
)c
to enter the command-line mode and type:
ls
# this prints a list of devices available, check which one is yours by looking at the contents with `ls (hdX,msdosY)/`
# From now on, I'm going to assume that (hd1,msdos1) is your USB partition
linux (hd1,msdos1)/Image.gz initrd (hd1,msdos1)/rootfs.cpio.gz boot
The device boots the kernel and the initramfs (that actually for the moment acts as a rootfs). Dropbear and dhcpcd should start automatically, if your network adapter is recognized you'll be able to:
ssh root@192.168.1.212 # (or whatever the ip is)
| Username | Password |
| -------- | --------------- |
| `root` | `surface-pro-x` |
If everything goes well, you have a rootfs to play around with and help us debugging the kernel problems further!
Booting without the devicetree works without any hang, but misses basically UFS and all the goodies (see previous post).
Booting with a custom DTS hangs the system on the classical:
The previous output is interesting as well (I'm sorry for the picture, I have no way to get a pretty dmesg since the system hangs):
cc/ @andersson, @shawnguo2
I have attempted to boot your Linux images per your instructions on my Pro X SQ1 however after I type out the commands and hit enter after "boot" - it seemingly sits there without any progress, is this correct or is something wrong?
Device Status
Booting with ACPI:
Booting with Device Tree: