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
<steev>
and it appears that pd-mapper is working fine here on the c630 as well
smpl has quit [Ping timeout: 480 seconds]
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<bamse>
steev: there's apparently a need for tying in the dp with usb type-c management, for some userspace requirement...so he's working on it
<steev>
ayy
<steev>
with 6.9 qseecomuefisecapp works on the c630, i should send a patch for that
<bamse>
readonly though?
<steev>
probably
<bamse>
i believe it uses ufs for storing those things...but i'm not sure
<steev>
that part i'm not sure about at all, i'm just figuring since i'm taking the time to update it, might as well see whats what
<bamse>
but if so, we need some sort of userspace thing to provide disk access for trustzone to be able to persist the changes
<steev>
i was able to do grub-install without it complaining that i need to finish the rest of it manually
<steev>
every so often, i do get some weird dvfs doorbell timeout or something about ufs when trying to reboot
<bamse>
but where you able to reboot and actually hit grub? or you already had grub among your boot options?
<steev>
i already had grub, but normally running that will complain that it wasn't able to finish successfully and i need to manually set the boot order or some such
<steev>
may need to*
<steev>
but i'm guessing it may have just read and saw that it's already properly set and not tried to write it?
<steev>
yep, that's exactly what it does
<bamse>
yeah, you're right...now it will probably tell you that it succeeded, but upon rebooting it might not be working
<travmurav[m]>
steev: bamse I looked at it recently and afaiu on the tz side you use it as usual but it caches the efivars in ram, and then one needs to make a special "sync" call to flush changes to disk, which no one would do on ufs/emmc targets
<travmurav[m]>
so I assume all devices can use uefisecapp but without the sync thing the ufs/emmc would be read only
<travmurav[m]>
and at least on my 7c the "sync" is just calling into qhee persistent storage thingie which I assume would handle the rpmb stuff
<steev>
travmurav[m]: have a link to where you do that?
<steev>
or are you saying what you've looked at on the windows side of things
<travmurav[m]>
so afaiu one would need to backport android's qhee rpmb callbacks and hook them up to actual rpmb, then it would probably just work (after adding an extra call to uefisec)
<travmurav[m]>
steev: no, I've only REd the blobs a bit
<steev>
oh
<travmurav[m]>
haven't tried to implement yet since it seems like every qhee/rpmb implementation from qcom is blob only :(
alfredo has joined #aarch64-laptops
possiblemeatball has quit [Remote host closed the connection]
<steev>
that's fair :)
<travmurav[m]>
s/qhee/qsee/ (the tz) across all messages, I mixed them up again...
possiblemeatball has joined #aarch64-laptops
<steev>
well that's above my pay grade :D
Dantheman825[m] has joined #aarch64-laptops
<Dantheman825[m]>
I had a thought
<Dantheman825[m]>
I wonder if my broken mute button light have something to do with a messed up dtb
<Dantheman825[m]>
* button light might have something
<Dantheman825[m]>
cause the light stays broken on every kernel I boot, and even live images on usbs
<steev>
does it stay broken in windows?
tobhe_ has joined #aarch64-laptops
tobhe has quit [Ping timeout: 480 seconds]
agl has quit [Ping timeout: 480 seconds]
checkfoc_us has quit []
checkfoc_us has joined #aarch64-laptops
agl-galaxy-arm64 has joined #aarch64-laptops
alfredo has quit [Remote host closed the connection]
agl_ has joined #aarch64-laptops
agl-galaxy-arm64 has quit [Read error: Connection reset by peer]
agl_ has quit []
agl-galaxy-arm64 has joined #aarch64-laptops
possiblemeatball has quit [Remote host closed the connection]
possiblemeatball has joined #aarch64-laptops
possiblemeatball has quit []
<Dantheman825[m]>
No, the light is functional on Windows
agl has joined #aarch64-laptops
agl-galaxy-arm64 has quit [Quit: bis denne]
agl-galaxy-arm64 has joined #aarch64-laptops
agl-galaxy-arm64 has quit []
smpl has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
possiblemeatball has joined #aarch64-laptops
agl7-Galaxy has joined #aarch64-laptops
agl7-Galaxy is now known as agl-Galaxy
agl-Galaxy has quit []
alfredo has joined #aarch64-laptops
<agl>
steev: Does your newest kernel als run on a Galaxy-Book-S notebook with Snapdragon 9cx Gen 1 Processor?
<agl>
s/9cx/8cx/
<agl>
jhovold: Do you know this also=
<agl>
?
<bamse>
travmurav[m]: that's in line with my understanding as well and i'm trying to aid in the effort of reaching a point where we have an open-source version of such solution
<travmurav[m]>
bamse: nice to hear
<travmurav[m]>
bamse: Is someone working on it @ quic/linaro/etc already or it still needs convincing qcom to allow the work?
<bamse>
travmurav[m]: the qcom team is looking at it
<travmurav[m]>
that is, if i.e. at some point I feel like trying to implement it based on RE while there is someone working on the same goal with better access to resources
<travmurav[m]>
ah
<travmurav[m]>
this is really nice to hear, thanks
ellyq has quit []
ellyq has joined #aarch64-laptops
<agl>
Does anybody use the Galaxy-Book-S notebook with Linux?
<travmurav[m]>
maybe jenneron at some point
<agl>
ok
<travmurav[m]>
but iirc it was problematic?
jenneron[m] has joined #aarch64-laptops
<jenneron[m]>
i don't use it anymore
<jenneron[m]>
my backlight is broken, wifi for some reason doesn't work for me anymore, also usb ethernet doesn't work for some reason, so i can't debug anything, can't even get logs
<agl>
jenneron[m]: You do not mor at the Galaxy-book-s ?
<\[m]>
<HdkR> "I'm going to get the Lenovo T14s..." <- neat so you can report in on the fan noise levels / spin up annoyance 🙂
<HdkR>
:)
<HdkR>
Worst case I just use the dev-kit when it launches
<\[m]>
damn that galaxy book 4 edge is actually rather attractive apart from the clearly abhorrent keyboard
<\[m]>
USB4.0, hdmi, usb A formfactor
<\[m]>
and no active cooling
<\[m]>
the keyboard looks like the one apple tried to force on its users some years back, the butterfly whatnot one - absolutely horrendous typing experience
<\[m]>
I got one by accident starting a new job and unaware of the recent evolution - it was so bad you couldn't even get used to it
possiblemeatball has quit [Quit: Quit]
<\[m]>
dedicate AI button my goodness this new world we live in
<\[m]>
s/dedicate/dedicated/
<\[m]>
why would lenovo hold off on modifying the t14s though, supply chain issue?
<HdkR>
Might just be a limitation of their site when an item is in pre-order
<\[m]>
might be the marketing pic that s misleaidng
<\[m]>
the keyboard looks to have higher edges in a vid
<\[m]>
HdkR: that would be the worst explanation lol
<HdkR>
They may also just be trying to get as many people to buy the overpriced preorder model that they can :P
<\[m]>
the rumoured permanent discount comes into effect only couple of months later?
<HdkR>
Not sure when they start doing their weekly "sales" after the productl launches
<\[m]>
so mm those oled screens are glossy not mat?
Dylanger[m] has joined #aarch64-laptops
<Dylanger[m]>
For me it's between the Surface Laptop 32GB SKU or the Lenovo T14s, Lenovo is much more expensive tho
possiblemeatball has joined #aarch64-laptops
ungeskriptet is now known as Guest8371
ungeskriptet has joined #aarch64-laptops
Guest8371 has quit [Ping timeout: 480 seconds]
<HdkR>
\[m]: "Anti-glare, anti-reflection, anti-smudge" I guess anti-reflection in this case is matte?
<\[m]>
if it's referring to what I saw e.g. on the edge 4, it's some sort of coating - so it's glossy but slightly less annoying
<HdkR>
Will be interesting to compare to my Macbook
KREYREN_oftc has joined #aarch64-laptops
JensGlathe[m] has joined #aarch64-laptops
<JensGlathe[m]>
If the T14s proves to be silent (boy do I hold a grudge for the last one, T420s 2012) iwill go for this. When I find the slightest excuse.
ungeskriptet is now known as Guest8377
ungeskriptet has joined #aarch64-laptops
<JensGlathe[m]>
* If the T14s proves to be silent (boy do I hold a grudge for the last one, T420s 2012) i will go for this. When I find the slightest excuse.
Guest8377 has quit [Ping timeout: 480 seconds]
<\[m]>
lol no shit I bought like a t480 and sent it back, too noisy
<HdkR>
Worst case I glue a 140mm fan to the bottom :D
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
KREYREN_ has joined #aarch64-laptops
KREYREN_oftc has quit [Ping timeout: 480 seconds]
KREYREN_ has quit [Remote host closed the connection]
jhovold has quit [Ping timeout: 480 seconds]
alfredo has joined #aarch64-laptops
<JensGlathe[m]>
I got 6.10.0-rc1 running on EL2, took a bit of work
<JensGlathe[m]>
Actually, not really. The root cause is somewhere in drivers/of/device.c, but I didn't feel confident enough to understand / fix the issue. Apparrently the smmu changes refactor a lot of parameters. domain init assumes it gets a valid map, where the previous parameters base and length are implicitly given, and as it seems this fails for arm-smmu-v3.
<JensGlathe[m]>
And as a follow-up error the mapping is wrong / fails. When you've booted from USB the system survives, you just don't have PCIe DMA. When you're booting from nvme like my box does, its game over.
<JensGlathe[m]>
So maybe a little more effort to set up a workable map from the dt data could make this work.
KREYREN_oftc has joined #aarch64-laptops
<steev>
do we even have an npu driver in the kernel?
hightower4 has quit [Remote host closed the connection]
<HdkR>
steev: What would the NPU be used for even?
<steev>
ai workloads
<HdkR>
Oh no
<HdkR>
AI in Linux
<steev>
where do you think it mostly runs?
<HdkR>
Hopefully in the cloud away from all of my devices :)
<Dantheman825[m]>
Well, if I’m given an NPU, I might toy around with LLMs
<adamcstephens>
I'd rather LLMs run on my own device instead of sending my data to the cloud
<Dantheman825[m]>
Yeah
<Dantheman825[m]>
But IDK if most Ai projects out there will even support this Snapdragon NPU
<Dantheman825[m]>
I’m not sure what QCom’s software stack looks like for this thing, it’s definitely not CUDA or ROCm
<bamse>
HdkR: you can use fastrpc and the hexagon sdk to run "compute workloads" on the cdsp/npu
<bamse>
HdkR: it's not magically going to start doing AI on you...
<bamse>
steev: so yes, we do have both cdsp remoteproc and fastrpc, which is the kernel components...think there's some fastrpc patches in flight, not sure if they relate to this though
<steev>
ah, we don't have fastrpc in debian :(
<bamse>
steev: and then you would be lacking the userspace pieces i presume
<steev>
well sure, because gotta make a qualcomm account to download the hexagonsdk stuff
<steev>
but, i have that anyway cuz i was trying to find the bluetooth chipset documentation :D
<bamse>
srini had a demo at Linaro Connect where he ran some image recogition on the npu on x13s...hoping to see a writeup or something on that
<steev>
oooh
mcbridematt has joined #aarch64-laptops
<steev>
though i did read through some of the AI hub stuff and the 40GB (ram+swap) requirement seemed kinda steep for training my own...
<steev>
especially if i need to keep it out of the cloud
<bamse>
steev: seems to be some really cool stuff there...but i've not had the time to look into the details
<steev>
i agree, that's why i was curious :D
<bamse>
tried to play with fastrpc and hexagon sdk a few years ago, but that's it