robclark changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Chrome OS Trogdor Devices - Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630 - Lenovo ThinkPad X13s - and various other snapdragon laptops) - https://oftc.irclog.whitequark.org/aarch64-laptops
<konradybcio>
The os is currently clueless about kb backlight
<steev>
lidswitch, touchpads and keyboard should all wake it up
<bamse>
steev: what's sorted?
<steev>
display blanking
<zdykstra>
hmm, closer. Display is staying on / I can boot to a getty. Keyboard isn't working though.
<bamse>
steev: that always worked
<steev>
bamse: i meant at boot time, it would blank if something because something
<bamse>
steev: i'm not aware of any progress there...so i don't think that's what i said
<steev>
oh, okay, maybe it was jhovold that said something about it
<steev>
or i'm an idiot (true) and it's still very much required
<steev>
but either way, my 2T should be here tomorrow, and i should be able to burn my fingertips off along with ema cuz i'm gonna follow his instructions to install onto the 2T
<robclark>
TIL: my x13s apparently has a touchscreen after all (not sure if it is v6.8-rc1 or recent update of something else, but now gnome-shell randomly decides I need an on-screen keyboard sometimes)
KhazAkar has quit [Quit: Connection closed for inactivity]
<bamse>
steev: the improvement that i'm aware of is that you're suposedly now able to suspend/resume with external display connected, without the edp dying
<bamse>
robclark: congrats...although i didn't think that pathc had made it in anywhere yet...other than johan's tree
<steev>
robclark: bamse fixed it, jhovold pulled it in
<bamse>
robclark: it was just a missing sleep() :)
<robclark>
heh, I didn't _think_ the sku I ordered had touchscreen.. it at least wasn't a thing I was _trying_ to get (but mostly I wanted the max RAM option)
<steev>
robclark: it's not just you, i swore i didn't order one either, but i have one
<adamcstephens>
how can you tell if it has a touchscreen?
<robclark>
I half way wonder if some "non-ts" devices actually have a touchscreen but just nerf it in acpi tables
<adamcstephens>
outside of booting windows
<robclark>
in my case, the on-screen keyboard actually works
<steev>
assuming you have my 6.7.2 or johan's 6.7.2+, it should work as a touch screen if you... touch it, otherwise, echoin 4-0010 or something
<robclark>
hmm, ok, looking up my part # it does have touch after all
<zdykstra>
hmm, i2c-hid-of.ko and i2c-qcom-geni.ko are in my initramfs, but still no functional keyboard on boot.
<zdykstra>
I wonder what I'm missing
KREYREN_oftc has joined #aarch64-laptops
mcbridematt has quit [Quit: Leaving]
mcbridematt has joined #aarch64-laptops
<steev>
can you either ssh in or use a usb keyboard?
<robclark>
it is a semi-unwanted feature in this case.. at least with desktop linux (I'm not trying to run CrOS or android on this thing ;-))
KhazAkar has joined #aarch64-laptops
<steev>
bamse: there's your t-b
<steev>
robclark: you can unbind it - `echo 4-0010 | sudo tee /sys/bus/i2c/drivers/i2c_hid_of/unbind`
<steev>
or you can just modify that udev rule file above to point to unbind instead of bind
<steev>
and use that so you don't have to remember to do it
<robclark>
hmm, that might be less intrusive for me than carrying a local kernel patch
<robclark>
I suppose the question is probably more about why g-s randomly decides I'm in tablet mode (which doesn't happen w/ other devices not in tablet mode which have a ts
<robclark>
)
<albsen[m]>
<steev> "but either way, my 2T should..." <- you'll be installing a fresh copy of debian?
<steev>
kali, actually, but yeah
<travmurav[m]>
EL2 news: I seem to have fixed whatever was causing sc8280xp (and apparently my device) a random crash on a jump from efi-stub to kernel proper
<steev>
oh hell yeah
<albsen[m]>
I have some notes from my setup, if you like - I was planning on turning them into a blog post but didn't get to it yet
<travmurav[m]>
1 make sure you can boot normally and have earlycon=efifb print stuff on screen
<travmurav[m]>
(as in, in el1)
<travmurav[m]>
2 Get the tcblaunch.exe (either from a windows install or from the archive I uploaded here)
<travmurav[m]>
3 Sanity check: run sltest.efi tcblaunch.exe and confirm that you see a green line
<travmurav[m]>
4 Try to boot linux after "load slbounce.efi" in efi shell, tcblaunch.exe must be in the root of the same disk
<travmurav[m]>
you should see at least earlycon logs on efifb
<travmurav[m]>
and then you should see the kernel being in total pain with broken remoteprocs
<albsen[m]>
travmurav[m]: is this a secure boot efi for x13s and other qcoms - similar to systemd-boot? (sry, not entirely following)
<travmurav[m]>
albsen: no, this is a tool that switches the cpu to EL2 to allow KVM or other hypervisor to run
<albsen[m]>
bcs they don't yet, right? I wasn't sure why I read somewhere that virtualization doesn't work yet.
<travmurav[m]>
yes
<albsen[m]>
haven't noticed it to be honest, I'm on lxc mostly. but thats great, let me know if you want me to run anything on my machine to help u test and debug. (if it doesn't break my system massively) :)
<albsen[m]>
the current instructions do look a bit scary ...
<travmurav[m]>
well, currently Linux relies on qcom's proprietary hyp firmware to boot things, and we try to run in it's place with this so... :D
<jglathe>
will test this new slbounce later, can cope with remoteprocs not working (but its nice if they do)
<steev>
well, on the x13s without remote procs, you won't have battery charging, so that's a bit of a pita
<jglathe>
On Volterra you get by with out remoteprocs, no battery anyway
rmsilva has joined #aarch64-laptops
<steev>
yeah, that's fair
<jglathe>
Could boot from nvme only the first months, until I found out to build the mhi stuff as modules
rmsilva- has quit [Ping timeout: 480 seconds]
<jglathe>
@robclark I have come to appreciate the touch screen on Ubuntu desktop, though. Never seen a display kb come up though.
<steev>
it does if you have... something installed, orca?
<jglathe>
Oh I'm glad it doesn't
<steev>
it's not so bad, works great on devices like the c630 where it's convertible
<jglathe>
there it makes sense, on the x13s not so much IMO
<steev>
i agree
jglathe_x13s has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
iivanov has quit []
iivanov has joined #aarch64-laptops
<albsen[m]>
jglathe: I've noticed that in your kernel config you've not activated NFT, maybe I setup the .config wrong. I used this command: make devkit_defconfig. just came across tailscale not starting because if that.
iivanov has quit [Quit: Leaving...]
iivanov has joined #aarch64-laptops
<albsen[m]>
* ignore - found the issue, didn't use the correct command
<jglathe_x13s>
ok
<jglathe_x13s>
I'm still tinkering with the devkit_defconfig. Current state of affairs: copy devkit_defconfig and laptop_defconfig to *.config, and apply them after make defconfig. Then, ake menuconfig and see what's enabled.
<jglathe_x13s>
Would like to have all usefull bells and whistles, but no SoC's I don't need in the base hardware
<jhovold>
dgilmore: ok, that's some progress. Last time we discussed this I believe you said unloading both modules allowed you to suspend, but perhaps you were just referring to the secondary issue that that the wifi firmware crashes on immediate wakeup
<jhovold>
That warning from the usb controller is indeed unexpected. This is the port closest to the screen. Do you have some charger/adapter connected there which is triggering a wakeup?
<jhovold>
With no USB devices connected (including docking station) you should not see any such warnings on suspend.
<jhovold>
Make sure you disconnect all USB devices next time to rule that out.
<jhovold>
As for keyboard backlight, that would still stay on during suspend for now.
<jhovold>
And the touchpad is a wakeup source. You can disable that in sysfs if you prefer.
<jhovold>
So it sounds like you are suspending successfully now, if the screen stays off until you use the touchpad.
<jhovold>
So back up, and determine which of the changes you did allows you to suspend (e.g. unloading the modem or wifi drivers, or disconnecting all USB devices)
<jhovold>
ema: I've documented all the kernel configuration options that a distro need to enable in the form of my minimal johan_defconfig:
<jhovold>
Just go through that one and make sure you got all the required bits enabled to avoid getting burnt again (pun intended) :)
<jhovold>
steev: the drm driver probe deferral when the panel driver is not loaded is gone in 6.8-rc1 but the screen still goes black temporarily during boot
<jhovold>
robclark: i would not recommend unbinding the touchscreen driver, the recently added driver reset support is questionable and would leave the device powered with reset asserted if you unbind
<jglathe_x13s>
re ath11k_pci on x13s and volterra: there are separate m3.bin, amss.bin depending on fw_version
<jglathe_x13s>
mine is ath11k_pci 0006:01:00.0: fw_version 0x110b196e fw_build_timestamp 2022-12-22 12:54 fw_build_id WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23 on the x13s
<jglathe_x13s>
I've loaded kvalo's specific amss.bin and m3.bin for my ath11k card, let's see how this goes
<adamcstephens>
steev: thanks. it does look like this machine has some touch capabilities
<adamcstephens>
(i bought it used on ebay so did not do the original customization)
<jhovold>
jglathe_x13s: just use what came with linux-firmware, the driver will pick the right version
<albsen[m]>
<_[m]123> "yeah dunno if live boot works..." <- yes it does, but u need 1) to have a supported usb (dont use ventoy) 2) the dtb on the first uefi partition with a specific name. but ubuntu iso is much easier, also boots using ventoy
<jhovold>
kvalo is the ath11k maintainer and feeds new fw to linux-firmware as it is released
<jhovold>
as I've tried to explain before (to you or Jasper IIRC), you can't force the Linux ath11k driver to use the windows firmware or boardfile, you have to use what is is in linux-firmware
<jhovold>
the problem is that you don't have a boardfile, and only Kalle and Qualcomm can give you one for the Volterra
<jhovold>
This has already been solved for the X13s, but it took a year to get the correct file
<jhovold>
until then you can try reusing the boardfile (calibration data) for some other board (e.g. the X13s) but performance will most likely suffer
<jglathe_x13s>
@jhovold I have a board file that works...? unpacked the one from linux-firmware, added entries for volterra with @Jasper[m]'s help, tested all unique calibration data available, settled on the ones for the X13s. Not perfect, but fairly usable. Seen speeds up to 468MB/s with it. And, sort of more important: BT works fine with these.
<jglathe_x13s>
Like, 10m or so of range
<jhovold>
ok, then that seems to work good enough even if it's likely not the right one (e.g. what windows uses)
<jhovold>
i'm not sure Kalle will merge it based just one that, though
<jglathe_x13s>
the specific amss and m3 trials are for trying to "debug" the suspend revolt of ath11k, I have it on all three devices.
<jhovold>
the x13s calibation data doesn't even work that well with the sc8280xp crd reference design, better than what we used before, but not as good as it should be
<jglathe_x13s>
I wouldn't expect it to. But where do you get the real data in usable format
<jhovold>
as i said, from qualcomm
<jglathe_x13s>
:)
<jglathe_x13s>
I can live with the status quo, but that suspend thing is a nagger
<jhovold>
what suspend issue are you referring to? I know this is for the volterra and not the x13s
<jhovold>
fw crashing on resume?
<Jasper[m]>
Hi guys, I've been testing slbounce on the x13s for a bit with TravMurav and we're currently running into an issue where some important drivers are crashing that impede boot. Currently the major hurdle seems to be that nvme isn't coming up properly, so my initrd cannot find root to decrypt.
<Jasper[m]>
Can someone with the device look at a dmesg and help debug the issue? I'm available to test suggestions or fetch more info from the rescue environment I land in, but I'm afraid I haven't figured out compiling fedora's distro kernel yet, so that'll have to be done elsewhere.
<Jasper[m]>
Whatever I'm running should be on the slbounce release page on TravMurav's github.
<travmurav[m]>
(iirc someone mentioned that's the pcie iommu and my current guess is that nvme fails because the iommu is not set up and nvme gets read-zero-write-ignore)
hexdump0815 has joined #aarch64-laptops
<jglathe_x13s>
@jhovold yep
<jglathe_x13s>
or what looks like it
<jglathe_x13s>
the crash says panel probe went wrong.
<jglathe_x13s>
hmm interesting
<dgilmore>
jhovold: nothing was plugged in, running on battery
<jglathe_x13s>
since the firmware somehow goes missing with slbounce, worth a try
<dgilmore>
jhovold: I guess it was suspending just fine all along, though after a few times wifi craps itself
<jhovold>
dgilmore: ok, no idea why you see that dwc3 warning on that port, i see it on one of the ports of the multiport controller but support for that is not upstream yet
<jhovold>
dgilmore: yeah, that seems plausible, except that i got the impression that you hit the wifi crash on every suspend attempt after waking up immediately
<jhovold>
and as I mentioned I've seen that wifi resume crash here two, but only 2-3 times in 1.5 years
<jhovold>
here too*
<dgilmore>
jhovold: I have stopped suspending, It definetly does not like coming back, eventually it drops out entirely and the system needs to be rebooted to get wifi working again
<dgilmore>
and it does not take many suspends to make it vanish entirely
<jhovold>
yeah, if you hit that all bets are off
<jglathe_x13s>
the fw crash o resume happens on volterra and x13s, so... no real difference
<jhovold>
would still be good to know why you seem to hit this more often than the rest of us (e.g. config or AP compatibility issue)
<jhovold>
jglathe_x13s: well the differnce is that only dgilmore seems to hit it often on the X13s so that's a pretty big difference, even if it turns out to have the same cause
<jhovold>
i don't even know if it
<jglathe_x13s>
hmm two different APs, one a Fritz!Box, one a NetGear WAP124
<jhovold>
dgilmore: perhaps you can try suspending when away from home at some point, just to rule that out
<jglathe_x13s>
same on Volterra, but different fw_version on the chip: fw_version 0x1106996e fw_build_timestamp 2023-10-13 07:30 fw_build_id WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
<jhovold>
jglathe_x13s: ok, yeah, that could possibly come into play here
<jglathe_x13s>
that's why im testing these odd files :)
<dgilmore>
jhovold: I can do that this afternoon. I need to go out. I'll take the laptop with me
<jglathe_x13s>
sdbox2 has the same fw_version and fw has crashed already - no specific amss/m3 loaded yet
<jhovold>
dgilmore: thanks
<calebccff>
does the c630 (and other QC laptops) support EFI SetVariable() at runtime? How does that work?
<travmurav[m]>
calebccff: is it UFS?
<dgilmore>
c630 uses UFS for storage
<calebccff>
Yes, I think the C630 will keep EFI variables in a uefivarstore partition
<jglathe_x13s>
you mean an explicit suspend, like from the gnome menu, right?
<calebccff>
but afaik the EFI runtime can't talk to UFS
<calebccff>
because the kernel owns it
<travmurav[m]>
afaiu on spi flash it's linux -> efi -> ??? -> linux -> tz trustlet -> spi flash
<calebccff>
but Linux doesn't implement the weird TZ client stuff to allow the EFI code to write to storage via a userspace daemon
<travmurav[m]>
so my guess would be
<travmurav[m]>
on emmc: linux -> efi -> ??? -> linux -> tz trustlet -> linux talks to rpmb on behalf of tz
<travmurav[m]>
and on ufs similar
<calebccff>
it makes sense that TZ would manage SPI flash, then the kernel would not be allowed to mess with it
<calebccff>
hmm
<travmurav[m]>
since on emmc the efivars are on rpmb
<travmurav[m]>
on aspire1 at least
<calebccff>
right, on UFS there's a partition for them
<travmurav[m]>
and I'd guess uefisecapp.mbn signs them with UDS
<calebccff>
but where is this "linux writes on behalf of TZ" stuff implemented?
<jhovold>
jglathe_x13s: please do, would be interesting to know if you only see this issue on volterra, but with a similar test setup (e.g. same AP, OS, ...)
<jhovold>
and if turns out to be the same issue we see on the X13s, perhaps it will come in handy that you can reproduce it reliably on volterra
<jglathe_x13s>
both run the same os and kernel, 6.7.1+, compiled from my branch.
<jhovold>
otherwise we'll have to ask dgilmore to test any prospective fixes :)
<dgilmore>
I have a volterra as well, I have yet to put linux on it
<jglathe_x13s>
what's keeping you ;)
<dgilmore>
too many distrations
<jglathe_x13s>
I know
<_[m]123>
I wonder what exactly clean up means lol dkpig reconfigure and update-grub did not help ☹️
<qzed>
calebccff travmurav: correct
<qzed>
there are some kinds of callbacks that the Kernel driver would have to implement and I never quite understood how to do that exactly
<qzed>
but it looks like it basically goes:
<qzed>
linux - efi kernel wrappers - uefisecapp efi functions - tz - qseecom callback handling - ufs - qseecom callback response - tz - uefisecapp - back to efi/linux
<jglathe_x13s>
hmm loaded the specific amss/m3 files on sdbox2 (volterra), too. Suspend will happen
<qzed>
roughly
<calebccff>
qzed: sounds horrendous :D is the UFS handling meant to be done in kernel space do you know?
<qzed>
You mean kernel vs user space? No idea...
<qzed>
I'd personally prefer if we don't have to involve user space for something as low level as that
hexdump0815 has quit [Quit: WeeChat 3.8]
KREYREN_oftc has quit [Ping timeout: 480 seconds]
<steev>
drive showed up, it's gonna be so hard to wait til the weekend to do the surgery
<steev>
calebccff: qzed: fwiw, on c630, if i try to say it's okay to use qseecomuefisecapp i get a lockup; i've had zero time to look into it more closely
<clover[m]>
you got a 2TB?
<steev>
yeah, they're on amazon now
hexdump0815 has joined #aarch64-laptops
<clover[m]>
wow
<steev>
it's 2024 so no longer best buy exclusive :)