Sonicadvance1 / linux

Linux kernel source tree
Other
38 stars 0 forks source link

Status #27

Open Sonicadvance1 opened 4 years ago

Sonicadvance1 commented 4 years ago

Device Status

Booting with ACPI:

Booting with Device Tree:

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

Dmole commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

Does it help?

kachapman commented 4 years ago

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

lewurm commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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

IMG_20210128_090732_205

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 commented 3 years ago

Apparently it gets stuck here after update_fdt: image

image

denysvitali commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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: Screenshot_20210130-151203

denysvitali commented 3 years ago

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.

941bd007-1a8e-4aac-97e3-f13a840384cb

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
denysvitali commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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?

3d866bfb-da5d-48bd-91ae-08cab1b22da9

maor26 commented 3 years ago

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 commented 3 years ago

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

denysvitali commented 3 years ago

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 commented 3 years ago

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

qzed commented 3 years ago

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.

mirh commented 3 years ago

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.

denysvitali commented 3 years ago

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

denysvitali commented 3 years ago

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

IMG_20210205_000034~2

RussianNeuroMancer commented 3 years ago

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

bm16ton commented 3 years ago

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 .

denysvitali commented 3 years ago

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

bm16ton commented 3 years ago

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 .

denysvitali commented 3 years ago

@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

bm16ton commented 3 years ago

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 .

RussianNeuroMancer commented 3 years ago

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

bm16ton commented 3 years ago

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 .

denysvitali commented 3 years ago

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

kmesg-1

bm16ton commented 3 years ago

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 .

denysvitali commented 3 years ago

This could be interesting (despite it's for ACPI): https://patches.linaro.org/patch/388626/

Together with: https://patches.linaro.org/patch/388625/

mirh commented 3 years ago

https://github.com/shawnguo2/linux/tree/laptops-5.12 https://github.com/andersson/kernel/tree/wip/sc8180x-mdss-gpu-embryo

denysvitali commented 3 years ago

It boots!!!

https://gist.githubusercontent.com/denysvitali/c75b6e4962ecf088dc8b72bed7e26c01/raw/80afb7745b630925e4537f9c16cea9bd5ef283d1/dmesg-spx-1.txt

denysvitali commented 3 years ago

Soo, a couple of things to get you up to speed as well:

Instructions (YMMV)

Prerequisites

Steps

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!
denysvitali commented 3 years ago

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:

image

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): boot-2

cc/ @andersson, @shawnguo2

Deinsti commented 3 years ago

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? IMG_20210402_171548