ChanServ 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
shoragan has quit [Quit: quit]
mrkajetanp has quit [Ping timeout: 480 seconds]
ellyq has joined #aarch64-laptops
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
alpernebbi has quit [Ping timeout: 480 seconds]
mrkajetanp has quit [Ping timeout: 480 seconds]
ellyq_ has joined #aarch64-laptops
alpernebbi has joined #aarch64-laptops
mrkajetanp has joined #aarch64-laptops
ellyq has quit [Ping timeout: 480 seconds]
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
tobhe has joined #aarch64-laptops
tobhe_ has quit [Ping timeout: 480 seconds]
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
mrkajetanp has quit [Remote host closed the connection]
mrkajetanp has joined #aarch64-laptops
<steev> JensGlathe[m]: same thing here - loaded up firefox 129.0.2-1, and loaded up https://burningman.org/live-webcast/ and see the same (or similar enough?) splat - https://paste.debian.net/hidden/e7ed2e3e/
rz_ has quit [Remote host closed the connection]
rz has joined #aarch64-laptops
mrkajetanp has quit [Remote host closed the connection]
mrkajetanp has joined #aarch64-laptops
geobang[m] has left #aarch64-laptops [#aarch64-laptops]
mrkajetanp has quit [Remote host closed the connection]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Max SendQ exceeded]
mrkajetanp has joined #aarch64-laptops
hexdump0815 has quit [Quit: WeeChat 3.8]
mrkajetanp has quit [Remote host closed the connection]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Remote host closed the connection]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
SpieringsAE has joined #aarch64-laptops
mrkajetanp has joined #aarch64-laptops
<SpieringsAE> anonymix007[m]: Can i somehow get the asus specific firmware files from the windows installation? I will try out your image later today
mrkajetanp has quit [Ping timeout: 480 seconds]
<steev> SpieringsAE: they're in c:\windows\system32\driverstore\filerepository
<steev> or some such
<steev> gotta find the .elf/.mbn (but there are also git repos on github that have x1e firmware in them)
mrkajetanp has joined #aarch64-laptops
<SpieringsAE> steev: Thanks! I'm looking to commit them to a repository so yeah
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
<steev> i generally keep a copy of everything in there, on an external drive, just to have a backup and look through it at my leisure (i'm on the Thinkpad X13s though which is the precursor to X1E)
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
<SpieringsAE> I was thinking of getting that one, but it was very expensive, over here at least. This asus one was more affordable, but the specs are very good for the price
mrkajetanp has quit [Ping timeout: 480 seconds]
jhovold has joined #aarch64-laptops
<jhovold> steev, JensGlathe[m]: I'm also seeing that stuck venus clock when streaming video in firefox as I mention when it was reported here last time
<jhovold> I've confirmed that it's a 6.11-rc1 regression and just sent a fix here:
<JensGlathe[m]> This seems to be new-ish, like 6.11-rc2?
<jhovold> I'll include it in the next wip branch
<JensGlathe[m]> applied, will test
<JensGlathe[m]> @steev the patch for suspend and ath11k seems to reduce the problem to previous levels
<JensGlathe[m]> I had one occurrence on the X13s (buffer too short), the Volterras stayed mum
<jhovold> the ath11k issue definitely existed before hibernation support was added in 6.10, but if it is a race as I suspect then any changes in timing could make the issue more or less easy to hit
<Jasper[m]> Wait, new suspend option for x13s?
mrkajetanp has joined #aarch64-laptops
<Jasper[m]> I missed that I think
<jhovold> no, just an ath11k feature
<Jasper[m]> Ahhh, I understand
<jhovold> but looking at the ath11k revert it mostly changes the suspend paths, so perhaps it just throws the fw off somehow
<jhovold> JensGlathe[m]: how big is the difference, you've seen the issue once now on the x13s with the revert compared to how often before the revert?
<SpieringsAE> anonymix[m]: Managed to boot with your arch image, sadly still can't fully boot because I don't have a usb c drive yet, but keyboard at least seems to work now
<JensGlathe[m]> it manifests more on the Volterras (all same ath fw). Wthout the patch I have it not very often, maybe 1/week on the X13s, 2/week on the EL2 Volterra, almost never on the other Volterra. With the patch all three started spewing errors, so much that I disabled WiFi on the Volterras.
mrkajetanp has quit [Ping timeout: 480 seconds]
<JensGlathe[m]> Since I sorta nailed the bsod issue to camcc-8280xp and sm8350 all of them run a long time without reboots
<jhovold> so difference is 1/week to 1/day or multipe times a day?
<JensGlathe[m]> yes
<jhovold> 1/day or several times a day?
<JensGlathe[m]> on the volterras several times a day
<JensGlathe[m]> on the X13s can't say for sure, less
<JensGlathe[m]> the WiFI stays operational in degraded performance state, so I also need to run dmesg -W to notice early
<jhovold> ok, thanks, may help if with tracking down the underlying issue, which I fear is still there
<jhovold> rc6 is out (early again)
<JensGlathe[m]> oh that's good, there were lots of fixes for x1e dt
<jhovold> yeah, I should be able to drop some 20 patches or so
<JensGlathe[m]> Does x1e have a sdhci controller integrated? Saw nothing in the dtsi
mrkajetanp has joined #aarch64-laptops
<travmurav[m]> I'd almost bet there is one but might be possible no one of the oems would expose it
<travmurav[m]> as in, I'd even bet there is two xD
<JensGlathe[m]> like sdc1 and sdc2 in acpi?
<jhovold> nice, 33 fewer patches in the rc6 wip branch
<travmurav[m]> (I've never really looked at x1e acpi or did any research but qcom always had two mmc controllers so I'd hope they're still there)
<travmurav[m]> with mmc2 being the cool one (though not as much on modern things)
mrkajetanp has quit [Ping timeout: 480 seconds]
<travmurav[m]> fun there is only "sdc2" in slim7x acpi
<JensGlathe[m]> and in the HP Omnibook X14 too
<travmurav[m]> oh fun I think there /is/ only the sdc2?
<travmurav[m]> so they only kept the (presumably still) funny 4 bit one and not the 8 bit one for internal emmc
<travmurav[m]> well I guess makes sense to discourage using internal emmc on those things xD
<SpieringsAE> what interface does UFS use on for example the samsung?
<travmurav[m]> interface as in?
<SpieringsAE> also I only really see the need for 1 right
<SpieringsAE> sdc
<SpieringsAE> sdio
<travmurav[m]> ufs is it's own thing, it's not at all related to mmc
<SpieringsAE> theres only really the sd card slot
<SpieringsAE> interesting so an entirely specific bus for it?
<travmurav[m]> only really the sd card slot <- no, especially if you consider phones which is what qcom mostly does, there is usually internal emmc + sd slot, so traditionally sdc1 is 8bit emmc and sdc2 is 4bit sd card (which at least on old things also had nidnt mux)
<travmurav[m]> yes, ufs is a completely it's own thing
<travmurav[m]> I mean if you want to dissect it, it's SCSI over "ufs" that uses mipi d-phy iirc
<travmurav[m]> but this is very much different physical and data design from mmc
<SpieringsAE> huh I've only heard of mipi in mipi-dsi and mipi-csi for displays and cameras, didn't know storage was also in its portfolio
<travmurav[m]> mipi has specs on different levels
<travmurav[m]> i.e. there is mipi d-phy and mipi c-phy, which are "wire" layer, then there is transport layers like csi/dsi that could use c/d-phy
<SpieringsAE> I see very interesting, I'll look into this more
<travmurav[m]> and UFS spec is jedec, not mipi
<travmurav[m]> (like mmc is also jedec spec)
<travmurav[m]> ah, it uses mipi m-phy not c/d
<travmurav[m]> but well, it's details already xD
<travmurav[m]> ugh is there a microsd slot in slim 7x or any other x1e laptop even?
<travmurav[m]> would be cool if nidnt mux is still there so you can mux the debug uart to the microsd slot still
ellyq_ has quit []
ellyq has joined #aarch64-laptops
<SpieringsAE> I don't think any laptop has 2 sdcard slots
<SpieringsAE> my asus definetly doesn't
<steev> jhovold: oh good to know, and nice to see the patch :D
<travmurav[m]> I mean the (only) sdcard slot, if present, would hopefully be connected to the x1e sdc2
<steev> jhovold: did you see my question about the pmu? https://lore.kernel.org/all/20240830191438.31613-1-danila@jiaxyga.com/ made me look at ours on sc8280xp, and aside from not having cortex-a78/cortex-x1 pmu definitions, i notice that our irq_trigger is set to high but everything else seems set to low?
<steev> i have https://paste.debian.net/hidden/dd637a15/ locally, but haven't set because i don't know enough to know if it should be low
<steev> haven't sent*
mrkajetanp has joined #aarch64-laptops
ellyq_ has joined #aarch64-laptops
ellyq has quit [Ping timeout: 480 seconds]
mrkajetanp has quit [Ping timeout: 480 seconds]
ellyq has joined #aarch64-laptops
ellyq_ has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
SpieringsAE has quit [Ping timeout: 480 seconds]
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
SpieringsAE has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
zdykstra has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Remote host closed the connection]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
<hogliux> kuruczgy[m]: JosDehaes[m]: I'm pretty sure my machine is not sleeping due to the following test: try starting a clean kernel compilation just before sleeping. Then let the machine "sleep" for 20 minutes or so. After 20 minutes "wake-up" the machine. Not only has the kernel finished compiling for me, but I clearly hear the fans spin up while the laptop is "asleep".
<hogliux> kuruczgy[m]: Can you true this experiment as well?
mrkajetanp has joined #aarch64-laptops
<hogliux> In the kernel logs I see "kernel: mhi mhi0: Requested to power ON". Is this maybe a hint on what's causing the machine to wake up? It's very generic as I think alsmost everyhing is connected to the MHI.
* travmurav[m] wonders if there is rpm sleep stats on x1e
<travmurav[m]> that is, if grep "" /sys/kernel/debug/qcom_stats/* and how much of those tick
<travmurav[m]> * ...exists and
mrkajetanp has quit [Ping timeout: 480 seconds]
<JensGlathe[m]> hogliux: hmm MHI is Modem Host Interface, ath11k / ath12k drivers use it to download some firmware afaiu. Otherwise MHI is intervowen with PCIe (which is the physical layer or something). But, when the WiFi drivers act up on Suspend (which appears to be an issue) this would sound logical.
<JensGlathe[m]> you can see the firmware loads with "dyndbg=file drivers/base/firmware_loader/main.c +p"
<JensGlathe[m]> like here
Caterpillar has joined #aarch64-laptops
mrkajetanp has joined #aarch64-laptops
systwi has quit [Remote host closed the connection]
mrkajetanp has quit [Remote host closed the connection]
mrkajetanp has joined #aarch64-laptops
<TSIN[m]> can we use sdhc from this dts?
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
<JosDehaes[m]> hogliux: Yes it's probably not really asleep. I put my machine into suspend at 75% in the evening and in the morning there was only 35% left. Seems a bit much even if the machine is not yet going in lowest power state
<travmurav[m]> for anyone who is interested in dual booting el1 and el2 via slbounce, I've threw together a version that checks the dtb for a flag and only switches if it's present, so you can have two boot options with normal and el2 dtb (apparently sd-boot doesn't honor uapi spec for overlays duh)
<travmurav[m]> the implementation is in this branch: https://github.com/TravMurav/slbounce/tree/switch-if-overlay
<travmurav[m]> you can create el2 dtb like this:
<travmurav[m]> sudo fdtoverlay -i /boot/sc7180-acer-aspire1.dtb -o /boot/sc7180-acer-aspire1-el2.dtb /boot/dtbo/sc7180-symbols.dtbo /boot/dtbo/sc7180-el2.dtbo
<travmurav[m]> I guess should make sure you have https://lore.kernel.org/all/20240517195021.8873-1-robdclark@gmail.com/
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
hexdump0815 has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
<JensGlathe[m]> TSIN: interesting. sdhci@8804000 matches what I see in the ACPI dump. Different interrupts though
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
SpieringsAE has quit [Ping timeout: 480 seconds]
<JensGlathe[m]> I would prefer to get this from qcom honestly
jhovold has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
Lucanis has quit [Ping timeout: 480 seconds]
mrkajetanp has quit [Ping timeout: 480 seconds]
clee_ has joined #aarch64-laptops
clee has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
zdykstra has joined #aarch64-laptops
mrkajetanp has quit [Remote host closed the connection]
mrkajetanp has joined #aarch64-laptops
ellyq_ has joined #aarch64-laptops
mrkajetanp has quit [Max SendQ exceeded]
mrkajetanp has joined #aarch64-laptops
ellyq has quit [Ping timeout: 480 seconds]
mrkajetanp has quit [Remote host closed the connection]
mrkajetanp has joined #aarch64-laptops
<steev> https://patchwork.freedesktop.org/patch/594572/ is what made it into the kernel travmurav[m]
<steev> bjorn's version*
mrkajetanp has quit [Max SendQ exceeded]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Remote host closed the connection]
mrkajetanp has joined #aarch64-laptops
Lucanis has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
<anonymix007[m]> This makes absolutely no sense. I have 2 kernels: one working only with USB boot (GRUB) and the second one that works with both USB boot (GRUB, only plain non-UKI boot tested) and NVMe boot (systemd-boot, only UKI works). The configs should be the same.... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/cvGTQBEhNjkZCZMEzLQDGTCF>)
mrkajetanp has joined #aarch64-laptops
<anonymix007[m]> This ("EFI stub: ERROR: Exit boot services failed.") happens with both UKI and plain vmlinux entries in systemd-boot with the broken kernel
mrkajetanp has quit [Max SendQ exceeded]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
mrkajetanp has quit [Ping timeout: 480 seconds]
<steev> anonymix007[m]: maybe you need bamse patch https://patchwork.kernel.org/project/linux-arm-msm/patch/20240819-uncompressed-distro-packages-v1-1-c8accc8bc9ea@quicinc.com/ (which needs reworking, but for testing purposes should be okay to test?)
mrkajetanp has joined #aarch64-laptops
<anonymix007[m]> Is "kernel once installed
<anonymix007[m]> can not be booted with systemd-boot" the same boot services issue I'm getting?
<anonymix007[m]> Though I don't have CONFIG_EFI_ZBOOT nor CONFIG_COMPRESSED_INSTALL set in my config
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops
<gabertron> /etc/X11/xrdp/xorg.conf
<gabertron> fyi: for those using xrdp for things, the latest version of xrdp on debian unstable arm64 for the laptops added something to by default disallow using glamor in xrdp unless you are in an allow list (not sure on the reasoning there) but it means you have to modify this file:
<gabertron> and modify this line:
<gabertron> edit this file:
<gabertron> Option "DRMAllowList" "i915 radeon msm"
<gabertron> ------
<gabertron> not sure how many people use xrdp but its one of those things that is nice for debugging during laptop bringup if the display isn't working but you can get in via the network
<gabertron> the line by default doesn't have "msm" so fails to use glamor / use the gpu
mrkajetanp has quit [Ping timeout: 480 seconds]
mrkajetanp has joined #aarch64-laptops