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
Ablu is now known as Guest4619
Ablu has joined #aarch64-laptops
Guest4619 has quit [Ping timeout: 480 seconds]
<DanaG>
I wonder if the rumored AMD ARM laptops will be any better than Qualcomm?
<HdkR>
That would be some wild speculation at this point
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
Lucanis has quit [Ping timeout: 480 seconds]
Lucanis has joined #aarch64-laptops
<steev>
i'm pretty sure the frame reassembly failed is coming from the uart and not bluetooth itself
<jhovold>
steev: the fact that bluetooth sometimes fails to probe is a bigger problem, it doesn't happen that often but still need to look into that when i can find the time
<jhovold>
manifests itself as commands timing out, qcom has a retry loop in the driver, which could indicate that this is a known issue to them
<steev>
i haven't seen that here, although occasionally i have issues with devices (mainly the airpods) connecting but i think that's not the driver itself but somewhere in bluez
push_ has joined #aarch64-laptops
<jhovold>
yeah, such device-specific compatibility issues may not necessarily be due to bugs in the x13s kernel drivers
push has quit [Ping timeout: 480 seconds]
<jhovold>
the bluetooth issue i'm seeing sometimes can look like:
<jhovold>
[ 36.576822] Bluetooth: hci0: Retry BT power ON:2
<jhovold>
you can't use the device until you've set a valid address
<konradybcio>
then maybe the userspace did it for me
<konradybcio>
i am watching youtube with my bt headphones connected rn and bluetoothctl list shows 00:00:00:00:5A:AD
<jhovold>
then something must have set it, are you still on ubuntu? perhaps they hacked something up to set that non-unique address which will cause collisions...
<konradybcio>
yeah still on ubuntu
<konradybcio>
at least made my way out of gnome ;)
<jhovold>
that progress at least :)
<jhovold>
that's
<konradybcio>
on one hand i'd switch, but otoh i'd love to see offical arch-arm64
<konradybcio>
but on the other other hand that will take a while
<jhovold>
yeah, so likely there's a glitch in whatever user-space thing is setting the address
<jhovold>
yeah, it would be great if we could get proper arch support
<jhovold>
or if at least alarm got get it's act together and update the kernel to 6.5
<jhovold>
clover[m]: updated it to work around some bugs in later versions of bluez, but it still looks fragile, perhaps ubuntu is using something like that
<jhovold>
in case you want to dig further
<jhovold>
s/hand/Hans/
<konradybcio>
so.. it can't retrieve the proper btmac, so shouldn't we be setting HCI_QUIRK_INVALID_BDADDR too, then?
<jhovold>
i
<jhovold>
konradybcio: i've already fixed that up
<jhovold>
what kernel are you on? not an old ubuntu one i hope?
<jhovold>
see 6945795bc81a ("Bluetooth: fix use-bdaddr-property quirk")
<konradybcio>
@jhovold oh, I just grepped for this quirk and noticed it wasn't present in our driver
<konradybcio>
as for my kernel.. depends which one i boot into, different kernels have different breakages for me xD
<jhovold>
heh, then you're on your own ;)
<jhovold>
with an old kernel you'd end up with the default bd_addr set, not with mainline
<konradybcio>
hm let's see if running that will fix bt for me on 6.5
<konradybcio>
also, i could not get next booting this week.. bisect time
<konradybcio>
which is less than ideal when you compile and test on the same machine
<Jasper[m]>
konradybcio: Time to get a volterra from the basement :^)
<konradybcio>
Jasper: so is yours collecting dust?
<konradybcio>
too bad the guy who got it up never sent things upstream
<Jasper[m]>
konradybcio: Yes and no, I've been moving it every time I wanted to get to the computer
<Jasper[m]>
There's a guy on github that says there's about 5 patches missing from upstream so that's good
<Jasper[m]>
I'm planning to find an easier way to get the needed mbn blobs instead of mounting the windows partition (since that won't work for everyone)
iivanov__ has joined #aarch64-laptops
goapz has joined #aarch64-laptops
iivanov__ has quit [Remote host closed the connection]
<goapz>
CAN WE CONTINUE THIS CONVERSATION AT IRC.SUPERNETS.ORG #SUPERBOWL FOR FUCKS SAKE
<steev>
Jasper[m]: the exe's on the lenovo website work, you just need to know the url, as well as have innoextract installed
<steev>
oh, unless you mean volterra
ungeskriptet is now known as Guest4701
ungeskriptet has joined #aarch64-laptops
ungeskriptet is now known as Guest4702
ungeskriptet has joined #aarch64-laptops
Guest4701 has quit [Ping timeout: 480 seconds]
Guest4702 has quit [Ping timeout: 480 seconds]
<Jasper[m]>
<steev> "oh, unless you mean volterra" <- correct
<_[m]1>
cute how they want to make a mac mini
<Jasper[m]>
_[m]1: More direct comparison is the A12Z DTK
<Jasper[m]>
but a metric ton less shit
<Jasper[m]>
I daily drove it on Windows for a while since it uses basically no power
<_[m]1>
Jasper[m]: this can mean multiple things
<_[m]1>
Jasper[m]: I read a quick review, it wasn't too positive
<HdkR>
If the next Windows Dev kit device uses sc8380xp, it will be nice to yeet these Mac Minis from my CI. Every few months the VM software fails to revalidate its license so I need to faff around in my server rack to get them enabled again
<Jasper[m]>
_[m]1: The Apple DTK had a timebomb and was extremely slow lol
<Jasper[m]>
_[m]1: wrong expectations
<Jasper[m]>
It's quick hardware, plenty RAM
<Jasper[m]>
Only thing I'd say is the video out being a bit flakey (fixed after some driver updates) and there being some coil whine
<_[m]1>
next is not the 2023 one? they are foreseeing next releases?
<_[m]1>
2024 will be hte year of desktop arm huh 😉
<steev>
actually 2024 will be the year of the linux desktop, 2025 will be the year of desktop arm ;)
<_[m]1>
goooo proton !
<Dylanger>
<HdkR> "If the next Windows Dev kit..." <- Would buy, I just really want raw EL2 access
<HdkR>
Dylanger: I have a feeling we'll never get EL2 on any Snapdragon. Gunyah seems to be the route they want to go
<steev>
jhovold: ahh, actually yeah, i have seen that, but not super often. i just asssumed it was my code tbh
<HdkR>
So we've already got pre-orders open for a sm8650 phone. How soon until ARM gifts us the CPU optimization guides? six months after launch?
<robclark>
what cores are in sm8650? x4? (And do we know what aarch version the nuvia core is and what extensions it supports?)
<HdkR>
robclark: X4/A720/A520
<HdkR>
No specs on the Oryon stuff other than fast
<Jasper[m]>
robclark: armv8.7
<Jasper[m]>
To the latter question
<robclark>
hmm, so no memcpy instructions :-P
<robclark>
but still, nearly the newest v8.. but kinda would have assumed v9
<Bioxvirizm-x13s[m]>
<juergh> "konradybcio, if you're having..." <- it's easier to freak out and put in an ARCH)
<HdkR>
FEAT_MOPS would be neat
<HdkR>
Give me that hardware accelerated memcpy and memset that match x86 behaviour :P
cyrinux has quit []
cyrinux has joined #aarch64-laptops
<Dylanger>
<HdkR> "Dylanger: I have a feeling we'll..." <- Then I hope for MediaTek to come out with something equally as good, they likely will, just takes like 1 - 1.5 more years
<Dylanger>
That or a PBL exploit to headshot Ganya
<Dylanger>
s/Ganya/Ganyah/
<HdkR>
One can hope
<robclark>
I think mtk has their own in-house hypervisor.. but not sure if it is open src
* robclark
is happy with whatever route gets crosvm/qemu working even if it isn't EL2
<robclark>
hmm, "Optimizations for virtualization and memory address translation"
<HdkR>
Definitely a curious one
wriapg has joined #aarch64-laptops
<wriapg>
/)))))))))
<wriapg>
//) __ __\
<wriapg>
C==/_o|^|o_\
<wriapg>
| _\ ) hey pls dont flood in my network also
<wriapg>
\ .--- / no colors and swearing is not allowed
<wriapg>
_/`-. __.'_
<wriapg>
/` \`'-,._./|\ this is my network i make the rules, buddy
<wriapg>
/ \ /`\_/\/ \
wriapg has left #aarch64-laptops [LOVE FROM EFNET]
<clover[m]>
wtf lol
<HdkR>
Bored children are bored
<steev>
its supernets again
<steev>
its a yearly thing they do to be annoying to other irc networks
<Dylanger>
<robclark> "I think mtk has their own in-..." <- They do, but it's not forced
<Dylanger>
The MT8195 on my Chromebook works with KVM
<Dylanger>
It's lovely
<robclark>
Dylanger: same is true for QC chromebooks.. just don't expect the same to be true for non-chromebook things (and the non-hyp way of doing protected content is clunky so maybe eventually CrOS will switch)
<Dylanger>
Good point, that's probably why there are no high power QC Chromebooks
<Dylanger>
This is why aarch64 Chromebooks are massively underrated imo, it's all open (as much as possible) or nothing
<robclark>
the hyp situation really doesn't have anything to do with market segment, the same sc7180 windows laptops boot in EL1
<robclark>
it's simply that current CrOS architecture requires KVM
<Dylanger>
I think that's a good thing, but Qualcomm will prob find a way to snake Ganyah underneath KVM?
<maz>
not without NV.
<robclark>
open vs not.. well there is also tz .. and all that uefi, etc.. on basically any "windows" laptop.. so meh
<robclark>
yeah, not sure when we get nested virt
<maz>
the fruit has it, so maybe someone will wake up...
<_[m]1>
anyone has real low level knowledge of the d8ff between armv8 and 9? is that last iteration as fast or?
<HdkR>
_[m]1: Difference is SVE
<HdkR>
An ARMv8.7 CPU that implements SVE turns in to an ARMv9.2 CPU
<robclark>
I thought there were some confidential computing type things? (And that you could have SVE on armv8?)
<HdkR>
Potentially? SVE is the only one I care about anyway :D
<robclark>
I was under the vague and possibly incorrect impression that v9 mattered more for server things
<HdkR>
The ISA doc is a bit vague, is the only difference between ARMv8.5 and ARMv9.0 the fact that AArch32 isn't supported at EL1/2/3?
<HdkR>
That might be the case?
<HdkR>
And EL0 is optional
<HdkR>
For Cortex designs it is when SVE2 was added
<robclark>
EL0 is userspace, how can that be optional.. other than that, I thought aarch32 was dropped for things higher than EL0 already?
<Dylanger>
<robclark> "I thought there were some..." <- Yeah I remember reading about this, supposed to next-gen TZ
<robclark>
or, did you mean aarch32 is optional for EL0? (I guess that would make more sense with aarch32 support getting dropped.. like does sc8380 even have aarch32?)
<HdkR>
robclark: Yea, aarch32 is optional for el0
<HdkR>
8380 is unlikely to support aarch32 considering 8650 will also be cutting it out
<robclark>
aarch32+el0 being optional seems way more reasonable than el0 being optional :-P
<HdkR>
Yea, derpy continuation of my thought there :D
<robclark>
:-P
<craftyguy>
are "pmic-glink failed to create device link" errors a known thing on the x13s (using 6.6-rc7 from jhovold's tree)