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
DanaG has joined #aarch64-laptops
<DanaG> Something strange I just noticed: the Surface Pro X came with a 65-watt charger, the Surface Pro 11 came with a 43-watt charger. What gives? The 11 uses more power, doesn't it? Also, I can't use either one comfortably, because ungrounded metal laptop = unpleasant tingling/vibrating sensation.
DanaG has quit [Remote host closed the connection]
echanude has quit [Ping timeout: 480 seconds]
anonymix007[m] has joined #aarch64-laptops
<anonymix007[m]> clee: we'll be lucky if X1E hw video decoding would be even posted on mailing lists this year.
alpernebbi has quit [Ping timeout: 480 seconds]
<robclark> anonymix007[m]: I've seen patches for "iris" already (but not sure what current state is, it isn't really something I follow)
alpernebbi has joined #aarch64-laptops
tobhe has joined #aarch64-laptops
tobhe_ has quit [Ping timeout: 480 seconds]
hipboi has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
hipboi has quit [Quit: hipboi]
alfredo has joined #aarch64-laptops
DanaG has joined #aarch64-laptops
<DanaG> I'm curious what the codename is of the Surface Pro 11, and especially the 5G model. Is the 5G model a different codename?
<DanaG> I'm guessing the X1 Plus will be later than the X1 Elite? I wonder how much they actually differ.
alfredo has quit [Quit: alfredo]
hipboi has joined #aarch64-laptops
hipboi has quit []
hipboi has joined #aarch64-laptops
hipboi has quit []
DanaG has quit [Remote host closed the connection]
hipboi has joined #aarch64-laptops
hipboi has quit []
hipboi has joined #aarch64-laptops
<JensGlathe[m]> Dev Kit is a jet engine from the sound profile, seems to be designed to transport some serious heat off
alfredo has joined #aarch64-laptops
alfredo has quit [Read error: Connection reset by peer]
alfredo has joined #aarch64-laptops
alfredo has quit [Remote host closed the connection]
alfredo has joined #aarch64-laptops
hipboi has quit [Quit: hipboi]
<macc24> <DanaG> "I'm guessing the X1 Plus will be..." <- some of x plus is a binned down x elite silicon, and some is entirely different design
<travmurav[m]> I like how they have two stickers/logos for x plus with different design to differentiate 8 and 10 core but there is literally no wording change :/
<travmurav[m]> it's as if someone knew this is a mess but couldn't do anything about it
<travmurav[m]> I guess they painted themselves into the corner as soon as they picked "plus"
<travmurav[m]> since what would be lower than plus? minus?
<JensGlathe[m]> no suffix
<JensGlathe[m]> like gpu
<travmurav[m]> well then it's ambiguous with the whole soc lineup
<abby> lite?
<JensGlathe[m]> cache coherency and naming things
<travmurav[m]> perhaps lite would work but no one in marketing likes to use "deminishing" names
<JensGlathe[m]> lite is burned. "s" would be sorta okay
<travmurav[m]> so as soon as you pick a "rating" kind of words, you can't use anything "below average"
<JensGlathe[m]> e for economy
<JensGlathe[m]> or c for cheapo
<travmurav[m]> in this case tried and true 9/7/5/3 system is kinda good, they already had to add 9 to extend it up, and can have 1 to go down xD
<maz> travmurav[m]: [ 0.417089] CPU: All CPU(s) started at EL2
<travmurav[m]> and in this case I kinda liked qcom's mobile lineup: 8/7/6/4
<travmurav[m]> maz: hooray
<travmurav[m]> what was it in the end?
<maz> fixed a buglet in slbounce.
<travmurav[m]> oh
<maz> you *really* want to synchronise the write to HCR, or the restore of the EL1 context doesn't do what you think it does.
<travmurav[m]> oh yeah I see...
<maz> as for the write to DAIF, this is self synchronising already, so the ISB is superfluous.
<maz> but that's not a real problem.
<travmurav[m]> well the real problem is that the person who wrote that (aka me) had no idea whatsoever on how exactly the thing he wanted to achieve should be achieved
<travmurav[m]> :D
<maz> man, you have no idea how grateful I am of your work!
<travmurav[m]> tbh at first the idea was even more ambitious as I wanted to longjmp into el2 while keeping the whole uefi alive, but it didnt work and, on x elite per your logs apparently they bring up a second core, which would've made this extra impossible
<travmurav[m]> since securelaunch must only happen on the only alive core
<maz> yeah, they have invented SMP EFI. just what you want for dodgy firmware!
<travmurav[m]> maz: but thanks for looking at it and debugging that, I would've probably never found this myself
<maz> travmurav[m]: well, that's the sort of crap I'm used to debug. and given the incestuous aspect of the Nuvia design with some of the Apple stuff, I'm fully expecting that the OoO window is absolutely massive, making this sort of problems much more visible.
<maz> ARM cores tend to be much more forgiving.
<travmurav[m]> I guess especially since it's in ooo I guess which wouldve been semi random since it clearly worked on other x elite
<travmurav[m]> it's funny how this code was even more broken and naive when I was first running it on old 7c1 and further we go more bugs like that we find xD
<maz> yup. typical frankenbug.
<travmurav[m]> on 8c3 I think we figured out cache was big enough to cause problems xD
<maz> hey, 15 years later, I'm still finding stupid bugs in KVM... :D
<maz> [ 0.519289] CPU features: detected: Nested Virtualization Support
<maz> there.
<maz> we're in fsckin' business.
<JensGlathe[m]> doesn't sc8280xp have this too?
<travmurav[m]> also nice they didn't use this for hyper-v and kept the old takeover code
<travmurav[m]> which they just ^C^V into the new gunyah codebase xD
<maz> no, client ARM cores don't have NV, only the server stuff. and not even all of them.
<JensGlathe[m]> Hmm only this Okt 04 17:37:37 sdbox2 kernel: CPU features: detected: Virtualization Host Extensions
<JensGlathe[m]> good to know, thx.
<JensGlathe[m]> Makes these discontinued boxes somehow pretty useful
<JensGlathe[m]> Is it the same for x1e-78-100?
<travmurav[m]> I'd guess it's all oryon/phoenix unless they artificially lock them down later
<travmurav[m]> maz: which email should I put as co-authored-by for the patch?
<anonymix007[m]> robclark: yeah, and not only does iris just support one codec or so, it is only for sm8550 and sm8250 AFAIR.
<minecrell> anonymix007[m]: x1e iris is pretty much the same as sm8550
<maz> travmurav[m]: maz@kernel.org if you can be bothered.
<travmurav[m]> maz: thanks, pushed the fix
<maz> cheers!
todi has quit [Remote host closed the connection]
<maz> it'd be interesting to understand why grub is so unhappy on this box though,
alfredo has quit [Quit: alfredo]
<JensGlathe[m]> did you preserve all the odd partitions of the builtin SSD?
<maz> I'm not using the internal SSD at all, everything is on external storage at the moment.
<maz> but a lot of the EFI support is there, so you probably want to keep them and only get rid of the last partition.
<travmurav[m]> maz: I think there is a common agreement now that grub tries to allocate arbitrary ram, gets regions in >32bit address range and explodes
<travmurav[m]> which it kinda shouldn't do but oh well
<maz> travmurav[m]: odd. I run grub on systems where all the RAM is above 40 bits, and nothing catches fire.
<travmurav[m]> yeah I have no idea why this happens, and also slbounce got reasonable memory <64bit when allocating things so idk what thsi all is about
<travmurav[m]> but seems like people patch grub or kill higher memory which apparently helps
<travmurav[m]> perhaps grub does something different with memory allocation since it's not actually a native efi app but ugh... grub
<travmurav[m]> maz: btw for grub+slbounce you may want to look at this grub patch https://lore.kernel.org/grub-devel/20240924-cmd-efidriver-v2-1-59ea78e058ab@trvn.ru/T/#u
<travmurav[m]> assuming we can figure out how to make it behave I guess :D
<maz> ahaha, awesome! yes, that'd be a valuable addition!
<zeph[m]> hi, alexeymin or Alex Marty u are not related to alexvinarskis on launchpad.net , right? tobhe do u have a clue what's the firmare dump from Windows 11 he is talking about? I didn't find specific documentation
<JensGlathe[m]> zeph: there are several tools to fetch the firmware files from Windows. My template for x1e related fw would be [this one](https://github.com/jglathe/wdk2023_fw_fetch/blob/jg/hp-omnibook-x14/bin/fetch_x1e80100_fw.sh). Correponding firmware hook for initramfs would be [here](https://github.com/jglathe/wdk2023_syshacks/blob/jg/hp-omnibook-x14/etc/initramfs-tools/hooks/x14-firmware). You could derive the Dell variant with the right
<JensGlathe[m]> fw path easily.
<zeph[m]> thanks Jens Glathe
<JensGlathe[m]> Oh you need a decrypted Windows partition for that one, I guess
<zeph[m]> yeah, I was already preparing myself for that xD
<robclark> maz: the ooo window is massive.. anadtech did a writeup with the info qc shared.. https://www.anandtech.com/show/21445/qualcomm-snapdragon-x-architecture-deep-dive/2
<HdkR> All the more painful when hitting a DMB and the store queues are loaded :(
<robclark> anonymix007[m]: re: iris, that is just the state so far.. AFAIU they split it up into smaller parts for upstreaming/review
<robclark> JosDehaes[m]: no audio yet.. idk if having to manually start the remoteprocs is a problem (do they need to be up and running before audio related drivers probe?)
<robclark> I don't see anything in dmesg about trying to load the tplg file
<robclark> could well have something amiss in my kernel config or something like that
<konradybcio> robclark the audio drivers will probe defer if adsp is not up as the clock drivers require it
<konradybcio> audio clock drivers*
<robclark> hmm, I don't have anything remaining in deferred_devices (at least not after I start remoteproc0)
<robclark> I _think_ I have all the x1e audio driver things enabled (=m) in my .config
<konradybcio> >Failed to get cgcr reset ctrl required for SW gating
<konradybcio> CONFIG_SC_LPASSCC_8280XP?
<robclark> no, didn't have that.. needed for x1e?
<konradybcio> yep
<robclark> ok, giving that a try
<robclark> `alsactl info` now shows something ... g-s doesnt' realize there is anything more than dummy output
<robclark> is pipewire still a problem?
<konradybcio> i have ubuntu+pipewire on the surface
<robclark> of maybe I need to restart some service after remoteproc0 is loaded?
<konradybcio> i don't see soundwire hsots coming up
<konradybcio> for me i need to modprobe some thing manually, like wsa884x... not sure why yet
<robclark> `modprobe snd-soc-wsa884x` didn't seem to do anything
<maz> HdkR: DMB only imposes ordering. DSB is what causes the damage.
thevar1able_ has joined #aarch64-laptops
thevar1able_ has quit [Remote host closed the connection]
thevar1able_ has joined #aarch64-laptops
thevar1able_ is now known as thevar1able
<macc24> robclark: fyi for you can use this config https://github.com/Maccraft123/Cadmium/blob/master/kernel/config.arm64 to check if you're missing something, as i've had audio kinda working on it + Jos's tplg and ucm2
echanude has joined #aarch64-laptops
ellyq has joined #aarch64-laptops
<kbingham> Hrm - my audio on my x13s has 'never worked' and I hadn't thought to check devices_deferred before ;-) - I see root@charm:/sys/kernel/debug# cat devices_deferred
<kbingham> soundsnd-sc8280xp: WCD Playback: codec dai not found
<kbingham> .... Does anyone know what provides the dai ?
<steev> maybe you're missing one of these modules? snd_q6apm,q6apm_dai,snd_soc_sc8280xp,snd_soc_qcom_common,q6apm_lpass_dais,snd_soc_hdmi_codec,snd_soc_lpass_wsa_macro,snd_soc_wsa883x,snd_soc_lpass_va_macro,snd_soc_wcd938x,snd_soc_wcd_mbhc,snd_soc_lpass_rx_macro,soundwire_qcom,snd_soc_lpass_tx_macro,snd_soc_wcd_classh
<kbingham> digging ... looks like I have modules for 'dai' - but they're not used... but there's an interseting message one up from the only 'dai' reference in the kernel:
<kbingham> [ 245.982435] qcom-apm gprsvc:service:2:1: CMD timeout for [1001021] opcode
<kbingham> So that probably means one of the remoteproc things isn't loading correctly as ever.
<HdkR> maz: Tell that to my emulator that sticks dmb fences before and after unaligned loadstores
<steev> kbingham: i get that message too, but definitely have working audio
<kbingham> argh red herring - thanks for checking
<steev> are you missing the tplg file?
<maz> HdkR: dmb really should be cheap, really. unless the implementation upgrades them to dsb to paper over terrible bugs...
<kbingham> the tplg files are there in firmware.
<HdkR> maz: I think it's just the sheer volume of them causing problems
<steev> and https://salsa.debian.org/kernel-team/linux/-/merge_requests/880/diffs are the 2 diffs debian added for audio
<steev> kbingham: https://salsa.debian.org/kernel-team/linux/-/merge_requests/842/diffs and this, just in case, was the first merge request to add in x13s support
<kbingham> Thanks - I'll sift through that .... I've always been building my own kernel from Johan's branches (+camera) and his config ... so I always assumed that would be enough. I'll do more
<JensGlathe[m]> maz: How did you get into the DevKit UEFI menu. No kb combination seems to work
<steev> if you're using johan's config, it definitely should work
<macc24> wait, does x1e not have arm32 support at all?
<robclark> nope, good riddance ;-)
<HdkR> macc24: ARM is dead, long live ARM
<robclark> aarch32 support was optional since the beginning.. and I'm sure MS wasn't wanting 32b legacy as a new arch started to take hold in that ecosystem, so it's just wasted gates
<robclark> (also, not qc related but pixel phones have dropped 32b support, as have newer cortex-x things)
<HdkR> Well, pixel things are newer Cortex-A and X that dropped the A32 support :P
<robclark> I think the mid/small cores might still have it? idk.. either way arm32 is pretty much on the way out the door
<HdkR> Completely dead on now
<HdkR> er, completely dead now
<HdkR> A520, A715, and X2 all killed it?
<robclark> ok, hadn't realized the newer mid/little cores dropped it too.. but makes sense.. previously they only kept 32b support in mid/little because china market (3rd party app stores)
sandman187 has joined #aarch64-laptops