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
svarbanov_ has quit [Remote host closed the connection]
svarbanov_ has joined #aarch64-laptops
svarbanov_ has quit [Remote host closed the connection]
svarbanov_ has joined #aarch64-laptops
eluks has quit [Remote host closed the connection]
eluks has joined #aarch64-laptops
luca020400 has quit [Quit: WeeChat 4.6.1]
luca020400 has joined #aarch64-laptops
davidinux has joined #aarch64-laptops
jglathe_volterra has quit [Remote host closed the connection]
jglathe_volterra has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
ravikant_ has joined #aarch64-laptops
ravikant__ has joined #aarch64-laptops
<alexVinarskis[m]>
bryanodonoghueI finally got ov02c10 working on Dell XPS 9345. Issue was with allocating dma buffer, increasing `cma=128M` to `cma=512M` in cmdline fixed it, in case this is useful to someone.
<alexVinarskis[m]>
I realized the camera activity indicator is not being used at the momement. In case of XPS its currently described as a simple LED. Is there a reason this was left behind, or just got overlooked? Assuming the latter, I did a quick POC [1] for camera driver to control indicator directly, works exaclty like one would expect. Unlike LED+camera-trigger, this way indicator cannot be easily disabled for malicious purposes.
<anthony25>
I dont know if something like this could be related to the bug on the yoga
<krzk_>
I think ov02c10 does not have indicator GPIO, so that's not correct hardware description
krzk_ has quit [Quit: leaving]
krzk has joined #aarch64-laptops
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
Yeah for the led I feel like what the comment suggests would be better: /* Reuse as a panic indicator until we get a "camera on" trigger */
<SpieringsAE>
I guess somewhere deeper in the camera subsystem this led trigger should be registerd
<alexVinarskis[m]>
[@_oftc_anthony25:matrix.org](https://matrix.to/#/@_oftc_anthony25:matrix.org) I don't think so, I got Yoga-equivalent issue on Zenbook, sensor doesn't even probe. Cma error would've come much later.
kalebris_ has joined #aarch64-laptops
kalebris__ has joined #aarch64-laptops
kalebris has quit [Ping timeout: 480 seconds]
kalebris__ is now known as kalebris
kalebris_ has quit [Ping timeout: 480 seconds]
jglathe_angrybox has quit [Remote host closed the connection]
srinik has joined #aarch64-laptops
pbrobinson_ has joined #aarch64-laptops
<SpieringsAE>
huh the waybar clock thingy apparently has been fixed some time recently, its no longer always displaying UTC or me on arm
<SpieringsAE>
wonder what the issue was
jglathe_angrybox has joined #aarch64-laptops
\[m] has joined #aarch64-laptops
<\[m]>
heya anyone been able to get 60Hz or more output on higher resolution over DP-altmode on t14s?
<luca020400>
I've been looking to get the slim7x, is there anyone "maintaining" a linux fork with all the required patches? I wouldn't mind running -next and manually handling some picks (like camss) but I couldn't find any real "source of truth" repo
<luca020400>
on that note, how would I go about actually making a distro build? I've dealt with qcom mobile socs on android for a good while, but that would be my first time at something different on arm..
<SpieringsAE>
JensGlathe: I managed to maybe kind of get 4k out of the hdmi port lol, but it was very not happy
<SpieringsAE>
luca020400: I can only speak for archlinux arm and maybe a little bit for debian, it is doable to bootstrap (debootstrap/pacstrap) your own image on a usb and then do it again for usb to system
<SpieringsAE>
at least that was my route
<SpieringsAE>
somebody shared some repo in here not too long ago though for building images
<SpieringsAE>
if your host system is x86 stuff like qemu-user-static/binfmt is very helpfull
<SpieringsAE>
debootstrap is kind of jank though, I have personally not found something better that fits my needs for debian unfortunately
<luca020400>
I was looking to use fedora, so that it would match my x86 laptop, but I can do archlinux, I used alarm long time ago (not even aarch64)
<luca020400>
I should be able to avoid cross-arch shenanigans, but working directly from x86 is def faster (more so if I need to build stuff from source), I'm used to llvm on kernel side so that wouldn't be a problem, but if something else in the stack needs to be cross-compiled it would be on me
<tobhe>
a lot of people here use jhovold's kernel https://github.com/jhovold/linux which has a few useful patches on top of mainline. Nothing slim 7x specific though afaics
<tobhe>
I think dgilmore might be able to help with fedora
<JensGlathe[m]>
my tree has some slim 7x patches on top of jhovold's for retimers, hbr3, sound, bluetooth iirc
<luca020400>
yeah went over that already, was mostly interested if there's _anything_ somewhat ready to use (even a script of sorts)
<luca020400>
I quickly went over the fork made by alexV, and now I already have some github forks to check out :)
<tobhe>
Don't know about any fedora scripts. I only have an Ubuntu iso :)
<luca020400>
thanks for the inputs
<JensGlathe[m]>
my kernels are ubuntu-x1e config. So the run with the Ubuntu Concept x1e 24.10 and 25.04.
<luca020400>
I'll probably end up with arch at this point, I can mess with that easily
<luca020400>
so I just need to add the specific EFI boot entries that point to the bootloader of choice and it should mostly work? first time with EFI on arm64
<tobhe>
efi boot entries should work just like they do on amd64
<luca020400>
ok that helps, I'm used to the uboot or qcom abl mess on android so that's good to hear
calebccff has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
srinik has quit [Ping timeout: 480 seconds]
kcxt has joined #aarch64-laptops
pbrobinson_ has joined #aarch64-laptops
ravikant_ has joined #aarch64-laptops
ravikant__ has joined #aarch64-laptops
<luca020400>
is kvm available by any chance? or they use gunyah?
<tobhe>
gunyah unfortunately :(
<travmurav[m]>
can kill it same way windows does, conditions apply
<maz>
KVM works if you boot at EL2 and are prepared to miss a bunch of features.
<luca020400>
sad, I saw some patches in lkml to support it along crossvm, but I have no idea if they would apply also here
<travmurav[m]>
iirc someone said x1e firmware uses incompatible api anyway
<luca020400>
maz: that I didn't know, so you can bypass it? and why would you loose something?
<luca020400>
oh well, qcom being qcom I guess
<tobhe>
Windows bypasses it entirely I think
<maz>
because this thing relies on some FW being loaded and verified by EL2, and undisclosed interfaces being used.
<maz>
if someone reverse engineers enough of this cruft, this could be made to work. but the incentive is extremely low.
<luca020400>
hmm shouldn't that be on QTEE side? or are they strictly tied together?
<travmurav[m]>
some functionality = whatever stuff they put into adsp (audio and charger/type-c stuff at least)
<maz>
luca020400: I don't really know, and really don't want to know.
<travmurav[m]>
there is something stupid but since qcom's hyp controls iommu, it kicks the dsp cores afaiu
kcxt has quit []
<travmurav[m]>
idk how windows handles this, I assumed they just have dsp boot implemented in the driver but recent mentions that "some bios update is needed to load signed-by-qcom blobs" makes me ask wth did they do there if the root of trust is seemingly hyp, which is gone after hyper-v loads
<luca020400>
maz: fair enough, was mostly curious :)
<travmurav[m]>
but per my understanding one still can just boot the dsp cores from el2 fine
<travmurav[m]>
just that noone knows how
kcxt has joined #aarch64-laptops
<luca020400>
I see that would make sense, will remain a mystery then
<travmurav[m]>
the idea of trying to boot the dsp from before el2 takeover was growing on me lately but not sure I want to touch this mess yet
<travmurav[m]>
I believe adsp-lite firmware can actually survive the switch but still want the full one to have sound working
<Radical[m]>
tobhe: hey the matching on line 71 in qcom-firmware-extract will fail if the user has a partition with a name longer than 9 characters, my systemd-homed is breaking it, switching to \s+ instead of [[:space:]] seems to resolve it.
<Radical[m]>
This happens because its only matching 1 space and the spacing is controlled by the longest partition name
<luca020400>
is that fw just for charging? x1e specific?
<travmurav[m]>
adsp runs stuff related to charger and type-c PD (so altmodes too) afaiu on 8c3 and x1e
<travmurav[m]>
and on phones too for the last few generations I guess
<luca020400>
I'm used to the android stack where xbl more or less has a minimal charging support and then you load the adsp with the proper audio+charge stacj
<luca020400>
so I guess the purpose is more or less the same here
<travmurav[m]>
yes, x1e is basically same stack as the phones youre familiar with I'd guess
<luca020400>
not sure if I should be happy about that
<travmurav[m]>
so per my understanding xbl/oem uefi boots adsp with "lite" firmware, then windows boots, takes over el2 via vendor-locked way (that we thankfully can use too) and then windows reboots the adsp with full firmware that has audio and other stuff
<travmurav[m]>
but right now we neither preserve the old adsp firmware that was preloaded nor can boot full one
<travmurav[m]>
since hyp's service is used in linux for that, how android phones do it in presence of qhee/gunyah
<luca020400>
checking the driver wasn't really in my plans, so it uses the same pas way to load fw and before that it unloads the lite one
<tobhe>
Radical[m]: thx, let me fix that
srinik has joined #aarch64-laptops
ravikant_ has quit []
Caterpillar has quit [Quit: Konversation terminated!]
Caterpillar has joined #aarch64-laptops
jglathe_angrybox has quit [Ping timeout: 480 seconds]
<SpieringsAE>
jhovold: I saw your name quite a bit in the net/wwan subsystem, so I wonder if you could give me a hint. I have this mpcie module sim7600G-H, it communicates with usb and serial. Is there some way to integrate this into a dts?
<SpieringsAE>
I can't seem to really find it if there is a way
<SpieringsAE>
same I guess with the gnss capabilities that the modem has
<SpieringsAE>
currently I just manually give it some AT commands, but yeah, kind of scuffed
<tobhe>
Radical[m]: looks fine to me. I can also cherry pick that into my repo if you make the LICENSE an extra commit
<sgerhold>
SpieringsAE: You can probably just use it fully over USB, then there is nothing to integrate in the dts
<SpieringsAE>
Currently 4G is over usb via the qmi_wwan driver
<Radical[m]>
tobhe: I just force pushed to the repo with that changed :)
<SpieringsAE>
but there seems to be some AT stuff required
<tobhe>
Radical[m]: actually if you make the \s+ an extra commit I'd take that too :)
<Radical[m]>
done
<tobhe>
thx!
erebion has joined #aarch64-laptops
<erebion>
I'm currently trying out connecting to this room via an IRC <-> XMPP bridge I've just set up for myself, please ping me should that cause any issues!
<SpieringsAE>
sgerhold: I think I may be looking to low, it seems mmcli has a lot more functionality than I thought
<SpieringsAE>
I will investigate that route some more
<broonie>
jhovold: Please just ignore Markus.
<sgerhold>
SpieringsAE: should be all controllable via ModemManager and QMI. The vendors of those like to add random AT stuff on top and recommend that, but at the core the QMI stuff from QC is usually still functional
<sgerhold>
and I think MM even uses some AT stuff too (via USB)
<sgerhold>
SpieringsAE: Or you just throw away whatever you have the sim7600G-H connected to and run mainline Linux on the sim7600G-H
<sgerhold>
that's what I did at some point :D
<jhovold>
broonie: heh, yeah, I usually regrett pretty quickly when engaging with him
erebion has left #aarch64-laptops [#aarch64-laptops]
erebion has joined #aarch64-laptops
<bryanodonoghue>
alexVinarskis[m]great to hear you've replicated on XPS - as regards LED it'd be nice to tie a LED to a V4L2 device generically as opposed to making it something qcom camss specific
<bryanodonoghue>
perhaps such a thing already exists
<bryanodonoghue>
anthony25 i think quite likely we aren't switching on the power rails for the CSIPHY on the Lenovo devices
<bryanodonoghue>
alexVinarskis[m]
<bryanodonoghue>
anthony25 difference being on the Dell those rails are likely already on
<SpieringsAE>
sgerhold: wait that is possible hahaha, I did just do a firmware update on one of these modules. Thanks for the advice anyway!
<alexVinarskis[m]>
<bryanodonoghue> "anthony25 i think quite likely..." <- Now thinking, both Yoga 7x and Zenbook have a hardware camera off button. On Yoga its slider on the right - any chance that switch was just off when camera was tested?
<bryanodonoghue>
i think that switch manually cover the aperture
<bryanodonoghue>
at least that's what it does on Inspiron
ungeskriptet has quit [Read error: No route to host]
<anthony25>
alexVinarskis[m]: I double checked, it wasn't
SpieringsAE has quit [Quit: SpieringsAE]
ravikant__ has quit []
deathmist has joined #aarch64-laptops
roy[m] has joined #aarch64-laptops
erebion3421EPVPN[m] has left #aarch64-laptops [User left]
srinik has quit [Ping timeout: 480 seconds]
hogliux has joined #aarch64-laptops
<hogliux>
@anthony25 @bryanodonoghue With bryanodonoghue's camera patches, are you seeing the `/dev/video/*` devices appear? Because three months back I also experimented with the cameras on slim 7x and the video device files did appear, but I couldn't get any userspace apps to communicate with them.
<alexVinarskis[m]>
bryanodonoghue : I found how to fix your missing csiphy supplies - they were named with `-supply` prefix, which is added automatically. With this (https://bpa.st/MKPA) change, dmesg error wrt to missing supplies is gone :)
<alexVinarskis[m]>
sadly, this did not resolve issue with csiphy clock not starting on zenbook, so it has to be (yet) something else
<hogliux>
@alexVinarskis[m]: Your link doesn't seem to work
<alexVinarskis[m]>
hogliux im getting lots of `/dev/video*`, but from dmesg its obvious that camss isn't starting. Wrt to userspace - it seems apps need to support pipewire video, and not directly attach to v4l2 device. On XPS where `qcam` does work, I still didn't manage to get pipewire to pick up the source, so until then other userpsace apps wont work. Quickly checking your branch seems you have different sensor than on Bryan's branch btw.
<hogliux>
OK I remember also getting errors in dmesg. Then ignore my branch.
<hogliux>
Most of the patches on my branch are from Bryan. I just added the dtb stuff I think.