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 joined #aarch64-laptops
shoragan has quit [Read error: Connection reset by peer]
<JensGlathe[m]>
fw file should be in the initramfs
<MrCatfood[m]>
is it gen70500_sqe.fw ?
<MrCatfood[m]>
<JensGlathe[m]> "hmm [looks okay](https://github..." <- i will recompile my kernel from this, is there a specific config I should use or use the default?
<JensGlathe[m]>
it is usually 3 files, gen70500_gmu.bin and gen70500_sqe.fw, and the specific qcdxkmsuc8380.mbn. The first two are loeded by the driver from qcom/, for the zap shader fw the path is in the dts.
<JensGlathe[m]>
re config: depends a little on the system you run. My config is basically ubuntu reduced to qcom platform. It should work with defconfig, though.
<MrCatfood[m]>
thank you, it clarified some things for me, I will give it another go
sri has joined #aarch64-laptops
<macc24>
<JensGlathe[m]> "fw file should be in the..." <- why?
<macc24>
msm driver tries to re-load the firmware anyway and with msm compiled into kernel and firmware files on the usual /lib/firmware it works just fine
<JensGlathe[m]>
if msm is not loaded as module? In my config it is loaded as module.
<JensGlathe[m]>
I will try it out, my impression until now was, gpu fw files better be available early
<macc24>
<JensGlathe[m]> "I will try it out, my impression..." <- i mean... i always built msm right into the kernel and just put all firmware files as normal onto the hard drive, and it worked just fine on sc7180 and x1e80100
<JensGlathe[m]>
You do boot from SSD, right
<macc24>
yes
<JensGlathe[m]>
Another world when you boot from USB type-c apparently
<travmurav[m]>
afaik just need the adsp firmware for usb
<travmurav[m]>
gpu firmware only if your splash is 3d accelerated /s
<macc24>
it works fine without usb - just don't load the firmware later on because it would re-enumerate all usb devices
<JensGlathe[m]>
yep
<JensGlathe[m]>
I will try and only put adsp into initramfs, lets see
<macc24>
why do you put firmware into your initramfs
<travmurav[m]>
you can get the thing to not loose the rootfs on usb if your initramfs reloads the adsp (and restarts usb power) before the said rootfs is mounted
<JensGlathe[m]>
adsp only "works", but cdsp will not be loaded later
<JensGlathe[m]>
the rest apparently will be loaded later
<travmurav[m]>
I think you can manually kick cdsp via sysfs but also is it even used by anything yet?
<JensGlathe[m]>
no idea
<anonymix007[m]>
travmurav: AFAIK CDSP is the only remoteproc that can run unsigned hexagon binaries, so it can be used to i.e. offload audio processing from the CPU. One would need to recompile the libraries for hexagon and it should work.
<travmurav[m]>
well I mean it's not actually used
<travmurav[m]>
but also eh double copying audio between cdsp and adsp sounds sad
<travmurav[m]>
I guess might be possible to zerocopy buffers but still eh
<travmurav[m]>
and then you can't do compressed playback I guess
<travmurav[m]>
(I guess not like one would care on laptops)
srinik has quit [Ping timeout: 480 seconds]
srinik has joined #aarch64-laptops
srinik has quit [Ping timeout: 480 seconds]
srinik has joined #aarch64-laptops
kalebris_ has joined #aarch64-laptops
kalebris has quit [Read error: Connection reset by peer]
kalebris_ is now known as kalebris
<erebion[m]>
I've installed Debian on my X13s, which just arrived. When booting up I get about 300 ms of systemd messages, then the screen turns black. I've got no idea what's going on as I cannot see anything and also have not yet set up SSH. Any ideas what's wrong?
<travmurav[m]>
is it exactly 30s after boot? :D
<erebion[m]>
Let me count
<erebion[m]>
You mean after pressing the power button or after the kernel loads?
<travmurav[m]>
after the kernel loads
<erebion[m]>
it's 8 seconds
<travmurav[m]>
mhm
<travmurav[m]>
does the screen blink between that?
<erebion[m]>
What do you mean?
<travmurav[m]>
if no, then my guess would be that msm (gpu driver) loads but there are some dependencies missing
<erebion[m]>
Probably, I have not yet successfully booted up to look at what's missing
<travmurav[m]>
there would be a moment where kernel kills uefi framebuffer and tries to start the gpu driver
<travmurav[m]>
which would look like the display turning off for a moment then back on
<erebion[m]>
If that is just milliseconds, then yes
<travmurav[m]>
so I guess display dying is that exact moment but something goes wrong
<travmurav[m]>
oh
<travmurav[m]>
then not sure
<erebion[m]>
Though I boot like this: ` linux /vmlinuz-6.10.11-arm64 dts=/boot/efi/sc8280xp-lenovo-thinkpad-x13s.dtb arm64.nopauth clk_ignore_unused pd_ignore_unused rd.driver.blacklist=msm 3 --- quiet`
<erebion[m]>
That should disable it, right?
<travmurav[m]>
what if you don't disable it?
<erebion[m]>
same
<erebion[m]>
Actually, I don't even get the systemd messages, but it's still black and I don't get anything
<erebion[m]>
<travmurav[m]> "there would be a moment where..." <- Can I stay in framebuffer somehow, get a shell and look at dmesg, add the missing firmware and then reboot and done..?
<travmurav[m]>
erebion 🏳️🌈♾: you need to make sure msm is not loaded at least, then I think what you have (clk and pd ignored, maybe also regulator_ignore_unused) should suffice to keep display alive
<travmurav[m]>
I'm not sure if rd.* is some initramfs implementation thingie tbh
<SpieringsAE>
are you where did you put your firmware and did you also use the dtb from that kernel?
<SpieringsAE>
look at the firmware path in the dts
<SpieringsAE>
should be like /lib/firmware/qcom/x1e80100/ASUSTeK/vivobook-s15/firmwarefile.mbn
<robclark>
so if it is trying to load qcom/x1e80100/qcdxkmsuc8380.mbn then the dts isn't giving the correct path
<SpieringsAE>
yep
<robclark>
maybe someone could send a patch to list to add the correct path for vivobook? IIRC that is still missing
<SpieringsAE>
yeah I dont have a vivobook anymore rip, maybe MrCatfood can help with that
<MrCatfood[m]>
i'm happy to help, i want to learn these lower level stuff of the os
<MrCatfood[m]>
btw they are missing, i tought the make file in the firmware repo copies them
<SpieringsAE>
I believe there are 2 sysfs files you need to read out, but cant quite remember which ones
<zdykstra>
lenovo has a 40% off "sale" going on right now, it brings the T14s Gen 6 down to a more reasonable price.
<travmurav[m]>
shame the firmware is a total mess
<SpieringsAE>
robclark: wasnt there a script somewhere that gets those values when grabbing the firmware
<kalebris>
erebion[m]: there's a ubuntu installer for the x13s, maybe can use that to bootstrap debian or at least be able to check the diffs in kernel params etc.
<erebion[m]>
I've already bootstrapped that using the Debian installer, I just need to figure out why the screen is just dark,
<robclark>
SpieringsAE: I think macc24 had some script to copy things to the right locations based on reading dmi fields from sysfs.. which seemed like a reasonable thing to follow
<travmurav[m]>
hm maybe some kernel modules are missing form the initramfs so it dies before being able to boot fully? I guess the installer itself worked fine?
<erebion[m]>
Yes, installer worked fine with the same cmdline
<travmurav[m]>
erebion 🏳️🌈♾: I'd try booting back into the installer, assuming it has live mode, then dump the initramfs to check what modues it includes and compare to lsmod of the correctly running installer
<robclark>
firmware-name should be something different.. the "unsigned" fw won't work
* travmurav[m]
remembers accidentally figuring out that one of those undocumented events happen when he presses f8 which ended up accounting to (non existent on the device) keyboard backlight
<travmurav[m]>
that is, on aspire1, and there was an unused connector on the mainboard that actually was powered/unpowered according to the state
paddymahoney has quit [Ping timeout: 480 seconds]
<erebion[m]>
Alright... It's just the LUKS key prompt that is invisible now, but I managed to boot up on the X13s. For some reason the screen is just black when unlocking.
bumble[m] has joined #aarch64-laptops
<bumble[m]>
x13s is my all time favorite
paddymahoney has joined #aarch64-laptops
paddymahoney has quit [Ping timeout: 480 seconds]
<macc24>
<robclark> "macc24: maybe you are already..." <- that's just thermistor temperature going over a threshold or something like that
<robclark>
ahh, could be.. I saw it when doing something that had cpu's and gpu spooled up
<travmurav[m]>
macc24: perhaps worth silencing known events then?
<macc24>
that might need proper handling in the future, as the dsdt changes thermal trip points
<macc24>
it's just... dsdt does stuff on that event and i don't know if i need to do it too or not
<travmurav[m]>
ah so I guess it has external sensor to control the fan? fun
<robclark>
re: "night-light" type things.. I'd need to check. The dpu isn't as stripped down as the 7c things so it might have more than just CTM
<travmurav[m]>
I guess it could still be nicer if the thermal governer and whatever magic schedulers now do for thermal capacity (at least I feel they do?) could also control the fan to keep it quieter but well
<travmurav[m]>
I guess first need the platform being useable
<robclark>
travmurav[m]: I expect there are both tsens sensors on the soc (ie. to keep the soc from melting) and external skin sensors (to avoid lap-burning)
<macc24>
there's a lot of sensors listed in dts files
<travmurav[m]>
robclark: ah I guess I will be sad with my 7c then? xD
<macc24>
and in dsdt
<travmurav[m]>
well obviously tsens is there but I mean right now there are two non-cooperating systems: kernel that uses tsens to throttle down the soc passively and ec that uses skin sensor(?) to actively cool
<robclark>
yeah, nothing really missing from sw standpoint on sc7180, the things that are missing are hw (and/or userspace support for doing things differently when hw isn't there, depending on your PoV)
<erebion[m]>
But I see robclark is quoted there on how to get battery percentage, thanks :D
<travmurav[m]>
> leds_qcom_lpg
<travmurav[m]>
lol that would explain why display dies I guess
<travmurav[m]>
if you don't have the backlight driver in your initramfs
<robclark>
travmurav[m]: correct them, that the _hardware_ doesn't support that (which I'd guess is pretty common on lower end arm things, like is it something that rpi supports?)
<travmurav[m]>
yeah I guess
<erebion[m]>
I read somewhere that the MAC address is not yet implemented and the kernel generates one on each boot. Has that changed? Not seeing anything about that in dmesg.
<bamse>
erebion[m]: that is correct still...
<bamse>
erebion[m]: for wifi...bt you need to specify one...
<steev>
there are things in the wifi for that too :)
<steev>
wiki*
* travmurav[m]
has wrote a funny thing in his dtbloader that sets the macs in dt to stable-random ones
<travmurav[m]>
idk if this can be applied to pcie wifi cards
<travmurav[m]>
the local-mac-address prop that is
<erebion[m]>
What wiki?
<travmurav[m]>
didn't get my hands to figuring out how to i2c in uefi still though
<steev>
JensGlathe[m]: afaik, ubuntu packages up all of the firmware as one, whereas debian splits them out into... split packages
<JensGlathe[m]>
yes I was confronted by this some time ago, but can't really remember
<JensGlathe[m]>
had something to do with free and non-free
<steev>
yeah, and now debian has the non-free-firmware component, so users can enable non-free-firmware without enabling non-free software
hexdump0815 has quit [Quit: WeeChat 3.8]
hexdump0815 has joined #aarch64-laptops
<hexdump0815>
robclark: travmurav[m]: lots of cheap and older arm systems (for sure mt8183 in kukui chromebooks, rk3399 but many more too) support color calibration the old style (i think its done via changing gamma curves?) - only qcom seems to stand out here :)
<erebion[m]>
steev Not exactly, Debian has a meta package for those that want all of them
<erebion[m]>
Also no bluetooth audio
<erebion[m]>
No audio at all
<steev>
You have to reboot after installing the firmware, if you haven’t.
<steev>
Bluetooth audio doesn’t rely on that firmware though
<steev>
I wrote the Bluetooth support because back then the audio driver didn’t exist and I wanted audio
<erebion[m]>
I have
<erebion[m]>
What's requried for bluetooth audio?
<steev>
Can you paste dmesg output?
<macc24>
so the debug uart on slim 7x is on the same uart as on crd - and the uefi is probably quite talkative, though my cables aren't reliable enough to make out anything more than couple of lines of linux output
<steev>
and do you have anything in /sys/kernel/debug/devices_deferred ?
<erebion[m]>
What is pd-mapper? I cannot find anything like that on this system
<steev>
it should be the service that was installed when you installed the protection-domain-mapper package
<erebion[m]>
3210000.soundwireqcom-soundwire: unable to get iface clock
<erebion[m]>
three times with different numbers
<erebion[m]>
soundsnd-sc8280xp: WCD Playback: error getting cpu dai name
<erebion[m]>
33c0000.pinctrlqcom-sc8280xp-lpass-lpi-pinctrl: Failed to get clk 'core'
<erebion[m]>
3240000.codecplatform: wait for supplier /soc@0/pinctrl@33c0000/wsa-swr-default-state
<erebion[m]>
and that four times with different numbers
<erebion[m]>
Oh and two of those are txmacro and rxmacro instead of codec
<steev>
i would first install the protection-domain-mapper service, and make sure pd-mapper service is started
<steev>
package*
<steev>
i would also make sure (i don't see it in the wiki) that you copy whatever the current kernel you have's dtb onto the efi partition, something like `sudo cp /usr/lib/linux-image-$(uname -r)/qcom/sc8280xp-lenovo-thinkpad-x13s.dtb /boot/efi`
<steev>
but audio won't start if the remote procs aren't running, and the remote procs won't start until you have the pd-mapper service running and have the firmware in place so it knows what to load (this should be only required until 6.11 comes out when pd-mapper moves into the kernel)
<macc24>
isn't 6.11 out already?
<steev>
as a debian package
<erebion[m]>
I've already added the DTB
<erebion[m]>
That was the first thing I did, already when booting the installer
<steev>
did anything change when you started pd-mapper?
paddymahoney has quit [Ping timeout: 480 seconds]
paddymahoney has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
<erebion[m]>
Will reboot in a couple of minutes, I've got something running I don't want to interrupt
<erebion[m]>
Then I'll know
<konradybcio>
does systemd-boot work ootb on 64gb t14s? steev
<steev>
I have no idea, I don’t have one yet
<konradybcio>
oh.. who had one then? hdkr?
<erebion[m]>
It works on the X13s, by the way. Just set it up. :)
<HdkR>
I don't know what systemd-boot is, and I still don't have mine setup because of the OLED problems
<MrCatfood[m]>
finally gpu works now on my vivobook
<MrCatfood[m]>
but on 6.12 squashfs is not working properly
<kuruczgy[m]>
macc24: Hope you are taking pictures. (Both of the probing setup, e.g. where the best probe points are on the board, and of the boards themselves in general.)
alfredo has quit [Quit: alfredo]
<macc24>
<kuruczgy[m]> "macc24: Hope you are taking..." <- i mean... you just take off the ssd and there's the uart, clearly labeled with nice 2.54 pads for a pin header
<macc24>
they're next to the edge of the board and under the ssd(not much space) so i didn't bother with soldering and just used test probes that latch onto stuff
<kuruczgy[m]>
they are thru hole?
<macc24>
yes
<macc24>
a plain goldpin header will work
<kuruczgy[m]>
ok 2.54 thru hole indeed seems easy to connect something to
<macc24>
unless you want an ssd lol
<kuruczgy[m]>
:D
<erebion[m]>
pd-mapper has not made the difference :/
<steev>
erebion[m]: can you show the output of systemctl status pd-mapper ?
<erebion[m]>
Though now I am connected but I still cannot use Bluetooth audio
<erebion[m]>
Had to install libasound2-plugin-bluez to have Blueman allow enabling audio, but still cannot set audio to Bliuetooth, usimg for example Pavucontrol
ahoneybun[m] has joined #aarch64-laptops
<ahoneybun[m]>
Has anyone seen a live disk of NixOS booting on the X13s yet?
<steev>
i think there are a couple people here doing nixos on the x13s
<ahoneybun[m]>
Mm I've never been able to get to the installer on it from any ISO.
<erebion[m]>
One of those solved Bluetooth: gstreamer1.0-pipewire libpipewire-0.3-dev libspa-0.2-dev libspa-0.2-jack pipewire-audio-client-libraries pipewire-tests
<erebion[m]>
But I'm not gonna uninstall them and reinsrall
<erebion[m]>
...and reinstall them one by one to find out
<erebion[m]>
(so annoying when I accidentally hit enter while typing a sentence....)
chrisl has quit [Read error: Connection reset by peer]
chrisl has joined #aarch64-laptops
<erebion[m]>
I just found out that enrolling my own Platfork Key does in fact not brick the X13s, but I also did not get Secure Boot working.
<erebion[m]>
I get the systemd-boot menu, then it just says "Security Violation". That's it. Just that.
chrisl has quit [Read error: Connection reset by peer]
chrisl has joined #aarch64-laptops
<erebion[m]>
Noticed this when looking at the journal: fb0: Framebuffer is not in virtual address space
<erebion[m]>
Does that looks like it is connected to the screen being dark while I unlock LUKS?