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>
dgilmore: do they show up if you add regulator_ignore_unused ?
<dgilmore>
steev: not tried
<dgilmore>
first I have heard of that one
<steev>
it is, the same concept as clk and pd
<steev>
-,
jglathe_ has joined #aarch64-laptops
jglathe_x13s has quit [Ping timeout: 480 seconds]
driver1998 has joined #aarch64-laptops
driver1998 has quit [Remote host closed the connection]
<clover[m]>
<\[m]> "I thought you figured it was..." <- That was johan defconfig. Had to enable f2fs then things worked
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
Segfault[m] has joined #aarch64-laptops
<Segfault[m]>
hey speaking of the adsp and type-c negotiation, does it allow data role swaps at all? i'd really like to be able to plug my x13s into another device and use it as a usb gadget but afaict that's not possible at the moment
possiblemeatball has quit [Remote host closed the connection]
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
possiblemeatball has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
possiblemeatball has quit [Ping timeout: 480 seconds]
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
f_ has joined #aarch64-laptops
f_ has quit [Ping timeout: 480 seconds]
<KieranBingham[m]>
Aha, I haven't been adding regulator_ignore_unused ... I'll try that too.
<steev>
it *shouldn't* be needed, but maybe fedora's config changes something that would
f_ has joined #aarch64-laptops
jglathe_ has quit []
jglathe_ has joined #aarch64-laptops
jglathe_ has quit [Remote host closed the connection]
jglathe_x13s has joined #aarch64-laptops
<jglathe_x13s>
KieranBingham[m] your picture looks like it's not loading a module, or (worse when booting from USB-C) like remoteproc firmware is not loaded or too late
<KieranBingham[m]>
Yes, the remote proc was discussed earlier too. So I think theres definitely something likely there. I would expect the ignore regulator unused to be related to the screen going black? Though I would be surprised if the display hasn't already been well handled given how many people are using the device
<KieranBingham[m]>
* Yes, the remote proc was discussed earlier too. So I think theres definitely something likely there. I could suspect the ignore regulator unused to be related to the screen going black? But I haven't check yet. Though I would be surprised if the display hasn't already been well handled given how many people are using the device
<jglathe_x13s>
booting up (especially from usb-c) has gotten increasingly picky since 6.8
<KieranBingham[m]>
There isn't another way to install first time except usb-c though right ?
<travmurav[m]>
extract nvme and write to that? xD
<jglathe_x13s>
Out of curiosity I would configure my current 6.8.1 image for X13s and see if it boots
<jglathe_x13s>
booting from nvme is way easier
<travmurav[m]>
But I guess the problem is still the fact that the adsp cpu controls the usb power bits and when we boot, we need to reboot that cpu...
<travmurav[m]>
Kieran Bingham: maybe you can boot some installer with rdinit=/bin/sh and we could get a shell to maybe debug why usb dies?
<jglathe_x13s>
yep. And this fries your boot rootfs. I "solved" this for Volterra, need to make a configured image for X13s
jglathe_ has joined #aarch64-laptops
jglathe_x13s has quit [Read error: Connection reset by peer]
<KieranBingham[m]>
Indeed, adding regulator_ignore_unused stops the screen from being disabled. Of course the next issue looks to be the remoteproc still.
<KieranBingham[m]>
After some time the installer actually reports something now, but it's not surprising :-) so we can ignore the installer complaints... But at least now I can see the output to debug steps
<wiley[m]>
jhovold: added a pile of modules to the initrd and it works now. Thanks! And great docs.
<wiley[m]>
Still finding that bluetooth earbuds don't work - will have to keep digging
<Segfault[m]>
oh shit, i finally updated the kernel on my x13s (from 6.8-rc4 to 6.9-rc4 lol) and now venus works! idk when that got fixed but it's great to see working, unfortunately ffmpeg seems to not like it and in gstreamer i was only able to get decode working, not encode, but that's still really awesome
<Jasper[m]>
Segfault[m]: Huh nice
<Segfault[m]>
i'd bet that was probably fixed when the allocation changes happened
<Segfault[m]>
the last few lingering hard resets also seem to have disappeared, so far this is rock solid now
<Segfault[m]>
now if only any browsers actually worked properly with v4l2m2m :P
<Segfault[m]>
actually wait it should work with firefox once whatever's causing ffmpeg to error out is fixed
<jhovold>
Segfault[m]: venus has been working (with gstreamer) here since I first added it to the wip branches a year ago
<jhovold>
can still trigger a reset if you try to transcode to some specific format (nv12) though
<jhovold>
but I also couldn't get firefox to use it via ffmpeg, hopefully someone will get that sorted at some point
<travmurav[m]>
yeah +1 to not being able to use firefox v4l2 support with venus on 7c1 either :S
<steev>
don't you have to flip something in the config?
<travmurav[m]>
ff sees that hw decide is "available" but I think what I saw in the log was it trying for one frame and giving up, falling back to sw
<kbingham>
I presume I can build a kernel+initrd and throw that onto my fedora install usb-stick? (I'll happily take a shortcut if anyone has a ready built 6.9 kernel+initrd that I can write this installer)
xroumegue has quit [Ping timeout: 480 seconds]
xroumegue has joined #aarch64-laptops
<Segfault[m]>
<jhovold> "but I also couldn't get firefox..." <- i couldn't even get it to work manually through ffmpeg so it seems to either be a problem there or some weird incompatibility between how venus and ffmpeg work
<Segfault[m]>
trying to just decode to a null output with ffmpeg using v4l2m2m gives me a `Device creation failed: -14.`
<Segfault[m]>
also strangely ffmpeg doesn't seem to have a v4l2m2m h264 decoder? dunno if that's some fedora thing or if there actually isn't one
<Segfault[m]>
it does have a h264 encoder
<travmurav[m]>
no "h264_v4l2m2m" in "ffmpeg -decoders" ?
<wiley[m]>
got bluetooth earbuds working by rebuilding the kernel again with a more generous config
<jhovold>
wiley[m]: which options did you need?
<wiley[m]>
I'll have to run through a diff tomorrow - I basically just took clover 's config from 6.7.10 and ran it through `make oldconfig`, referring to your defconfig for anything that wasn't obvious
<wiley[m]>
blunt, but it seems to have worked
<Segfault[m]>
<travmurav[m]> "no "h264_v4l2m2m" in "ffmpeg -..." <- nope, i do have h263, mpeg 1/2/4, vp8 and vp9 but no h264
<travmurav[m]>
weird, it should be there...
<jhovold>
wiley[m]: I guess it may be something like CONFIG_BT_HIDP, if you could confirm I'll make sure to enable that too
<kbingham>
Ho hum. I'll merge the softisp to libcamera already without me testing it. I know others have tested it ;-) I'm not getting this x13s booting any time fast.
jglathe_sdbox2 has joined #aarch64-laptops
<jglathe_>
kbingham hmm writing my image to stick for a test
<Segfault[m]>
ah damn, i tried software decode and v4l2m2m encode in ffmpeg and got another hard reset
jglathe_ has quit [Remote host closed the connection]
<steev>
i just used the kali (debian testing) installer and it just worked following the same steps as the debian wiki
<steev>
still wishing we'd get monitor mode firmware for the wifi, but we're more likely to get native el2 before that ever happened
<kbingham>
I've just merged the current softisp work now anyway. So next libcamera-0.3 should be able to run video calls on the x13s through firefox/pipewire. So I really want Fedora as I think that's the most up to date on pipewire camera portal integration. I don't know if debian and others will have all that yet.
<kbingham>
javierm, Or rather ... here ... do you have an x13s ? ;-)
<kbingham>
otherwise I think I'm going to ship this to bryanodonoghue and get him to set it up for me next ;-)
<jhovold>
kbingham: setup arch on my x13s a very long time ago when there was no distro support at all so haven't tested any distro instructions or images
<kbingham>
jhovold, Indeed, I expect that's the case for many ;-)
<jhovold>
but I got the impression that the debian one was pretty straight forward, many people have at least managed to a distro up an running
<jhovold>
:)
<kbingham>
So I'm here on the edge and failing :-(
<jhovold>
you shouldn't rush it though, that way you're bound to miss some important step, i know it's frustrating...
<jhovold>
what were the symptoms when the debian installation failed to boot, for example?
<kbingham>
quite ;-) ... I don't think I've rushed. But it's quite difficult with many separate paths, and different symptoms, that I would suspect are down to different packagings in the different images I've tried, along with the different set of (known) issues in different places.
<kbingham>
for instance, it's now clear I need regulator_ignore_unused to keep the display on. and the clock / power domain ignores are already a given.
<jhovold>
no, you don't need it unless you have some other issue
<kbingham>
Then I have that other issue ;-)
<jhovold>
and to debug the underlying issue you may need it...
<kbingham>
:-)
<jhovold>
if your machine fails to boot, regulator core turns of the backlight regulator after 30s
<jhovold>
so it's just a workaround for that
<kbingham>
Oh ok - so if the display actually comes up it will get a ref on the runtime_pm and not be unused. That's fair.
<jhovold>
fails to boot without first having setup the display susbsystem, to be more correct
<kbingham>
But it would be nice to keep the display console on anyway ;-)
<kbingham>
but this indeed meant that I couldn't see the other issues that were happenign in the earlier iterations. It was only this morning that I saw I could add the regulator_ignore_unused to see my other underlying issues. So several of whatever I hit last night are undiagnose.
<jhovold>
it's a known general issue, you currently need to make sure you have the deps to run your display in place
<kbingham>
undiagnosed.
<jhovold>
things depend on distro and config which complicates things, but in principle it's really simple :)
<jhovold>
you can build my latest wip branch, using johan_defconfig, include the two-three deps documented in the commit message for that config
<jhovold>
you need grub installed, and uefi entry to launch it
<jhovold>
and a grub config that loads the dtb from the efi partition
<jhovold>
that's it
<kbingham>
Sure ... but getting to that first sttep is the hard part ;-)
<jhovold>
cross compiling?
<kbingham>
Oh no. I can compile a kernel of course ;-)
<kbingham>
Getting a bootable image to boot into linux for the first time when only windows is on the device.
<jhovold>
ok, i thought that was solved a long time ago by the distro folks
<kbingham>
Though - I think that's clearer to me now
<Jasper[m]>
I honestly don't understand what changed
<jhovold>
i set up a bootable usb stick manually myself at the time
<kbingham>
The ISO's from both ubuntu and fedora don't boot out of the box for me.
<kbingham>
hence may 8 hours of pain ;)
<Jasper[m]>
I had both of those work fine a while ago (minus the instructions on the wiki, but that didn't need more than a grub config change)
<jhovold>
but you said you got the debian installer to run, can't you just use that?
<kbingham>
but I think what's clearer to me now is that I probably don't have to use an ISO ... I can run one of the images live from a usb and then I can more easily update that image
<kbingham>
The debian installer only boots into their text installer. That then didn't boot.
<kbingham>
(once installed) ... though tehcnically - that has installed grub for me - so I have "a" grub.
<jhovold>
you only need a text installer
<kbingham>
But I can only access that grub ... in it'sself.
<jhovold>
sounds like you just need to debug the last step
<kbingham>
I have not yet at any point had a terminal console I can execute commands in.
<jhovold>
e.g. a missing kernel parameter, or grub not finding the dtb
<kbingham>
indeed. So the installed grub, I can't now add a file to it - but the dtb should be on the ESP saved in from windows. But I can't see how to reference the ESP dtb from that now installed grub. (Though earlier I was told the bios will load that in for me if it's just dropped in the root of the esp partition, but that seems a bit too magical to me ... I'd expect something more explicit)
<jhovold>
yeah, i don't rely on the EFI magic to load the dtb either
<jhovold>
grub has a console, you should be able to list the content and make sure the config matches what's on disk
<kbingham>
So ... how would I manually get the 'known' dtb into whatever grub debian netinst has loaded? I assume the worst case fall back is I take out the nvme drive, and get an nvme->usb connector to hook it up to my pc and write the file ... but that feels likie I've gone to the extreme to end up with that ;-)
<jhovold>
not sure why it didn't work out of the box, perhaps debian relies on having the firmware load the dtb by default
<kbingham>
uefi/grub is foreign to me. I want uboot and a tftp server ;-)
<jhovold>
i'm sure the answer is in the debian wiki somewhere...
<Jasper[m]>
kbingham: Check the grub config. Find the location of the `linux` image, place the dtb next to it and then point a `devicetree` line to the same path (while changing the file from zImage to the dtb)
<Nios34[m]>
kbingham: maybe get it into the installation media and use devicetree command in grub?
<jhovold>
yeah, i'm glad i don't have to mess with it regularly either
<Jasper[m]>
In the meantime, I will try to see if I can reproduce the issue on fedora
<kbingham>
We're mixing so many scenarios here ;-) I have grub on the nvme drive - but I can't write files to that. I have grub on USB sticks ... and I can write to that.
<kbingham>
I'm still intrigued what jglathe_x13s's uplaoding soon refers too though ;-)
<Nios34[m]>
kbingham: make grub load the dyb file on the usb stick i guess?
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
<Jasper[m]>
@[Kieran Bingham] I figured it out. The default grub config expects the partition with the rootfs to have a certain label name as opposed to using the UUID for the drive. Gonna try doing the iso extracted to ESP setup again and see if changing the label name fixes it. For reference, I can boot to gnome with the wiki instructions if I leave the label from dd/gnome-disk-utility/fedora-media-writer intact and point to the dtb that's
<Jasper[m]>
already on my internal nvme drive
neobrain has joined #aarch64-laptops
<Jasper[m]>
<KieranBingham[m]> "1000024619.heic" <- It explains this^ process trying to repeatedly execute the initfs hook with `/dev/disk/by-label/Fedora-whatever`
<travmurav[m]>
is this the LIVE: stuff?
<Jasper[m]>
Yes
<travmurav[m]>
ah yeah that would make sense, iirc it has cdlabel hardcoded in it
<Jasper[m]>
Gonna try to redo the setup again, but see if changing the label does anything
<travmurav[m]>
iirc I was looking into dracut logs at some point as I was trying to boot installer copied to an sd card and it's just normal path but you need to prepend live so it uses the squashfs file
<travmurav[m]>
fwiw I didn't get it to work but that might be because I was trying to use stock installer on 8916 xD
<Jasper[m]>
travmurav[m]: It works, but not if you want to write stuff like a DTB to it xD
possiblemeatball has joined #aarch64-laptops
neobrain has left #aarch64-laptops [#aarch64-laptops]
echanude has joined #aarch64-laptops
<Jasper[m]>
@dgilmore @[Kieran Bingham] can confirm swapping out the CDLABEL in grub.cfg, to whatever the label of the partition is, fixes the issue and allows you to boot into gnome
<Jasper[m]>
Especially important if you want to extract sc8280xp-lenovo-thinkpad-x13s.dtb from kernel-core (cc @[Kieran Bingham] )
<Jasper[m]>
and put it on the partition
<KieranBingham[m]>
That's not where I expected the issue to end up :-)
<Jasper[m]>
Me neither, hadn't encountered that before. Maybe the LIVE label is new?
<KieranBingham[m]>
Thankyou very much for looking into it! How do we record this so no one else hits it I guess
<Jasper[m]>
I would add it to the fedorawiki page, but I already ran into the issue before that I have no write permissions :^)
<Jasper[m]>
KieranBingham[m]: By the way, if you're configuring FDE, be sure to chroot into the install from the livedisk and regenerate the initramfs using dracut. You can add the modules in https://github.com/jhovold/linux/commit/7117a34783221c0ad89f9d7f59d819bc24a54d34. If it complains about some modules not being present, you can remove them. It's likely that they may already be included in the kernel instead.
<KieranBingham[m]>
Yeah that's my stopping point too. No wiki write access
<KieranBingham[m]>
I wasn't going to go fde assuming it wouldn't work :-) but I can try it
<Jasper[m]>
You will not need the msm and qcom_q6v5_pas module blacklists in grub config when it's installed
<Jasper[m]>
And if you throw a recent dtb on the root of the esp, it'll automagically pick it so you don't need the devicetree line on grub
<Jasper[m]>
KieranBingham[m]: Oh yeah it works, just need to have the modules in that commit message included.
<KieranBingham[m]>
Dtb is already in esp indeed. I don't understand how the bios knows to find it though
<Jasper[m]>
I can also recommend including the firmware folder for sc8280xp into initramfs since that'll solve some other misc issues
<Jasper[m]>
KieranBingham[m]: Only requirement is the location and that the linux boot option is enabled
<travmurav[m]>
Kieran Bingham: iirc the file name is just hardcoded
<Jasper[m]>
KieranBingham[m]: Change that one to what you named it
<KieranBingham[m]>
So I just remap that to match F40 on my disk.
<Jasper[m]>
And the one above it aswell
<Jasper[m]>
KieranBingham[m]: Yes, you can check /dev/disk/by-label/ if you want to be sure
<Jasper[m]>
Jasper[m]: The one that sets the root for grub, might make pointing at the DTB a tad easier
<KieranBingham[m]>
retrying ...
<Jasper[m]>
regulator_ignore_unused is not necessary ntw
<Jasper[m]>
*btw
<KieranBingham[m]>
... GUI ... ;-) At last! Thanks - now I can go through the installer.
<Jasper[m]>
Yes! Good luck. Be sure to check the things I mentioned before
sri has joined #aarch64-laptops
<\[m]>
waw I thought fedora was more easy 😲
<lollaritits[m]>
\[m]: i was told to use fedora because its more stable
<lollaritits[m]>
i am now starting to doubt that
<\[m]>
it is cutting edge though, maybe not bleeding just
<\[m]>
maybe you can try rocky linux if you want something more stable
<Jasper[m]>
<\[m]> "waw I thought fedora was more..." <- It is easy, we just have exotic hardware :p
<Jasper[m]>
<lollaritits[m]> "i am now starting to doubt that" <- Nah Fedora is fine, bootstrapping it on ARM hardware may present some issues if not well supported :p
<kbingham>
.. and misuse of expected procedures ;D (extracting an ISO to a FAT partition)
sri has left #aarch64-laptops [Leaving]
<Jasper[m]>
Yeahhhh well that should be fixed once dtb's are also included on the partition itself
<Jasper[m]>
But you're absolutely correct otherwise
<lollaritits[m]>
<Jasper[m]> "Nah Fedora is fine, bootstrappin..." <- is it better than archlinuxarm
<lollaritits[m]>
i dont need to reinstall my os if its the same / worse
<Jasper[m]>
lollaritits[m]: The same in what sense?
<lollaritits[m]>
just overall Stability
<\[m]>
I meant more easy to install ootb without changes
<Jasper[m]>
<lollaritits[m]> "just overall Stability" <- I mean Fedora treats arm64 as a first class citizen, just not every platform
<Jasper[m]>
Haven't had issues with outdated packages or late releases
<\[m]>
arch is a rolling release afaict as where fedora is basically redhat beta
<\[m]>
both are bleeding edge imo
<Jasper[m]>
\[m]: Yeah it's slightly behind rawhide which __is__ rolling
<\[m]>
that's why people use rocky linux or equivalents if they want to stay in enterprise linux side of things
<\[m]>
you have alma and so-called centos streams
<\[m]>
where rocky linux is from where I"m sitting more hmm community driven
<Jasper[m]>
\[m]: It's doable. I like that it runs the upstrean kernel.
<Jasper[m]>
*upstream
<Jasper[m]>
I kinda miss that from ubuntu/debian
<\[m]>
that's the whole point no?
<\[m]>
ubuntu runs newer kernels tho
<Jasper[m]>
\[m]: Not by default iirc
<\[m]>
lol if I reference centos streams should I mention oracle linux? haha
* Jasper[m]
shudders
<\[m]>
I'd run rocky linux ór suse one, what's the name
<\[m]>
tumbleweed whatnot
<Jasper[m]>
Yes
<\[m]>
I have a samsung book go 5g on the way btw
<\[m]>
I looked a bit in suse ecosystem, and I must say, pleasantly surprised except that they stopped supporting ceph ;(
<\[m]>
I think 1 or 2 people here successfully installed tumbleweed
<Jasper[m]>
\[m]: Yes, me and someone else
<Jasper[m]>
Issues were similar to Fedora
<\[m]>
but not the CDLABEL thing?
<\[m]>
tumbleweed is a rolling release too !
<Jasper[m]>
\[m]: Not that I know, though Fedora didn't have that either
<\[m]>
for now we'll keep the oral tradition alive then, for sure I'll be asking in a month in here about it for the opensuse install haha
<lollaritits[m]>
<\[m]> "I meant more easy to install..." <- okay so i wont benefit from it
<lollaritits[m]>
my system is as configured as i could
<lollaritits[m]>
waiting for a new sim to hopefully get 5G working again
<kbingham>
Jasper[m], What's the (new) correct place to update grub.cfg now that fedora 40 is installed on the nvme ? ( it's booting \o/ ) ... I had to manually edit the grub line to add in the nopauth,{clk,pd}ignores of course so I don't' want to do that on each boot. But that has a more complex configuration structure now.
<\[m]>
which module you ahve for the sim ?
<\[m]>
\ /etc/default/grub
<kbingham>
Aha, ok so I just update the GRUB_CMDLINE_LINUX= there.
<Jasper[m]>
the args flag adds them remove-arguments removes them
<Jasper[m]>
update-kernel can be pointed at specific menuentries or at ALL for all entries
jglathe_x13s has quit [Remote host closed the connection]
<lollaritits[m]>
<\[m]> "which module you ahve for the..." <- just the default
<lollaritits[m]>
same as on the previous installation
<lollaritits[m]>
it got to the point where everything was connected but no traffic went through
<kbingham>
I assume the battery level indicator always being zero is a known / expected issue on x13s ?
<lollaritits[m]>
but well putting it in my phone made shit go even more wild
<lollaritits[m]>
it was detected as a no sim
<Jasper[m]>
kbingham: Recent issue, not sure where it's from
<Jasper[m]>
Can you check /lib/firmware/sc8280xp/ and see if they have a xz file extension?
<kbingham>
no :( looks like I broke it already. It's not booting since I called grubby and rebooted.
<kbingham>
Not even giving me a grub line to edit.
<\[m]>
battery not showing charge levels was related to pdmapper no?
<kbingham>
oh. ... never mind. Now it's up ...
<Jasper[m]>
\[m]: Yes, but in this case it's firmware not loading (quick enough)
<kbingham>
Maybe I was impatient. That was like a 45 second load time to grub ?
<Jasper[m]>
kbingham: Grub doesn't show by default, only if boot fails or if you spam esc (iirc)
<kbingham>
Ah. Ok so boot is failing then ;-)
<Jasper[m]>
kbingham: Likely yes hahaha
<kbingham>
I don't have the rd.driver.blacklist=msm. I'll add that back in.
<Jasper[m]>
kbingham: Shouldn't be needed
<Jasper[m]>
I don't think I have that, one sec
<kbingham>
argh. well it's probably not that. I removed quiet, and it showed more progress but then reported pdmapper error and rebooted.
<Jasper[m]>
Jasper[m]: I don't indeed
<Jasper[m]>
kbingham: pd-mapper the service?
<Jasper[m]>
Also did you install with full disk encryption?
<kbingham>
Jasper[m], No - I tried to enable encryption but it said I couldn't encrypt /boot ... so i unticked that.
<jhovold>
kbingham: battery status works fine on X13s, maybe not on Fedora and apparently not with your installation
<kbingham>
But I now seem to have lost my windows install / boot loader anyway ... so maybe there was no benefit in trying to preserve that.
<kbingham>
(I don't care to keep windows except for the message about updating firmware ... but I guess that ship has now sailed)
<Jasper[m]>
jhovold: Yeah Fedora doesn't include the firmware in initrd by default. Something tries to probe it and then fails because no firmware
<Jasper[m]>
kbingham: You can upgrade firmware when booting from usb
<travmurav[m]>
i guess pd-mapper crashes without .jsn files in that case? sounds sad if the init system decides to kill everything when it fails tho :S
<kbingham>
If I end up reinstalling (which suddenly seems like it would end up happening) that will give me the full 256GB then.
<kbingham>
I still seem to be so far from being able to run the camera which is the only thing I care about ;-)
<Jasper[m]>
Otherwise windows probably hasn't disappeared, but fedora likely bumped its own uefi bootoption to first in the list
<Jasper[m]>
travmurav[m]: It shouldn't, hasn't for me either
<kbingham>
Jasper[m], There's no windows options at all anymore. I can't even boot windows from f12
<Jasper[m]>
kbingham: Ah, bummer. Fedora normally behaves nicely if you point it at empty space
<Jasper[m]>
Also the service isn't needed anymore I think? Or am I confusing it with qrtr
<travmurav[m]>
afaik pd-mapper move to kernel is still ongoing and incomplete? not sure if it was accepted yet
<travmurav[m]>
qrtr-ns is in the kernel for a long time though, yes
<Jasper[m]>
Ah nvm, my mistake
<Jasper[m]>
<Jasper[m]> "Line 457 https://paste.centos...." <- I've had it mess up on warmboot^ before, but it didn't crash then
<Jasper[m]>
It didn't crash before either, when I was messing around with including firmware in initrd
f_ has joined #aarch64-laptops
<jhovold>
travmurav[m]: moving pd-mapper to the kernel was rejected, at least in it's current form
<travmurav[m]>
oh, unfortunate
Mathew has joined #aarch64-laptops
mcbridematt has quit [Remote host closed the connection]
jglathe_x13s has joined #aarch64-laptops
jglathe_sdbox2 has quit [Remote host closed the connection]
<dgilmore>
Jasper[m]: I am grabbing last nights livecd iso now to test
jglathe_sdbox2 has joined #aarch64-laptops
<dgilmore>
battery monitor on fedora works once you install the pd-mapper service. which is a requirement of the x13s package "dnf copr enable jlinton/x13s; dnf install x13s"
<dgilmore>
realistically lenovo should be shipping the dtb inside of teh bios
f_ has quit [Ping timeout: 480 seconds]
jglathe_x13s has quit [Remote host closed the connection]
jglathe_x13s has joined #aarch64-laptops
<dgilmore>
hrrm, so removing and reinserting my NVMe drive seems to make linux see it again. but something changed between 6.8.4 and 6.8.6 that broke being able to read the battery
<steev>
kbingham: jhovold: re: esp/debian grub; it doesn't get specified, it's passed in when you have the linux [beta] config option; so whatever dtb is in there, is in there. from grub, you'd pass the dtb of a different kernel by it's path on the filesystem itself
<dgilmore>
looking at the fedora packaging changes I have to believe that it is an upstream change . pd-mapper is still running okay
<Jasper[m]>
<dgilmore> "looking at the fedora packaging..." <- Issue got fixed as soon as I added uncompressed firmware to initrd
<jglathe_x13s>
so you just copy a dtb into the ESP (root I guess) and it will be used when booting linux with grub?
<\[m]>
lol rocky linux will support upstream lts kernels going forward seems (this is what you mentioned right Jasper)
<abby>
jglathe_x13s: yes, /boot/efi/whatever.dtb
<dgilmore>
jglathe_x13s: yes. with the linux option toggled. what it does is looks in the root of the ESP partition for the dtb file, it loads it and passes it in
<\[m]>
maybe it's because redhat further obscuring some part of kernel code or what was it
<jglathe_x13s>
hmm. And grub simply has no devicetree statement and EFI tries this instead?
<KieranBingham[m]>
What happens if there are two dtb files?
<jglathe_x13s>
I have it toggled, inclined to try
<KieranBingham[m]>
I assume this is something specific in the x13s firmware not an efi standard?
<dgilmore>
KieranBingham[m]: there can not be 2. it only loads /sc8280xp-lenovo-thinkpad-x13s.dtb
<jglathe_x13s>
that was my thought too
<jglathe_x13s>
so it must be this filename
<KieranBingham[m]>
Ok so it can't be whatever.dtb mentioned above. It has to be precise
<jglathe_x13s>
I guess I'll try. BTW, the Ubuntu 24.04 install ISO from 04/15 goes into an odd loop with xhci and timeouts, errors on setting up IOMMU (what) and dies. Never seen this yet
<jglathe_x13s>
KieranBingham[m] new image is compressing, ofc there were minor issues - now loading X13s BT qca/hpnv21.b8c, and the firmware hook for initramfs wasnt expecting zstd compressed GPU fw. It is an odd image, but you end up with a nearly fully working system - haven't tested any camera stuff, though
<Jasper[m]>
<\[m]> "lol rocky linux will support..." <- Yeah partly, Fedora will upgrade constantly though which is fine for.me
<dgilmore>
That is post a little silliness of the 6.8.4 and 6.8.5 initrds. the new dracut pulls in the modules. but not the firmware
<dgilmore>
adding the firmware compressed or uncompressed should fix it
<jglathe_x13s>
abby I'll give it a try. What do you mean with config, the .config of the kernel?
<abby>
yes
<Jasper[m]>
dgilmore: Hah nice
<Jasper[m]>
Explains a lot
<Jasper[m]>
dgilmore: Good to know
<dgilmore>
Jasper[m]: so with the firmware, you should be able to actually boot from usb without blacklisting qcom_q6v5_pas
<Jasper[m]>
dgilmore: That too? Interesting.
<Jasper[m]>
Thought that was a completely separate thing
<dgilmore>
Jasper[m]: well I am assuming so. what happens is that the module gets loaded, the usb bus gets reset and the usb-storage moves from sda to sdb. I am assuming in the initrd it will get scanned earlier so the drive you are booting from will not vanish and come back as a different drive
<Jasper[m]>
dgilmore: Makes sense, but wouldn't that technically already be covered by the init hooks looking for the label instead of a sdX device?
<dgilmore>
forcing qcom_q6v5_pas to not load causes the usb bus to not be reset.
<jglathe_x13s>
seems to be sort of worse. the rootfs device throws I/O errors (but stays the same). It es game over at that moment, it is not really a reset, it is a short disruption of power.
<dgilmore>
Jasper[m]: no because it happens halfway in the boot. it has mounted the filesystem, and loaded the kernel module from disk. then the drive goes away and is no more
<dgilmore>
even if the reset causes the drive to change from sda to sdb, if it happens in the initrd it will be okay, because it will be before the filesystem is mounted and it will be found, though perhaps that would throw an error due to duplicate ids
<dgilmore>
It is all very fragile, and qcom seem to have made it all a big miss
jglathe_x13s has quit [Remote host closed the connection]
<Jasper[m]>
<dgilmore> "Jasper: no because it happens..." <- Ahhhh okay, that makes sense. I assumed wrong
<KieranBingham[m]>
<jglathe_x13s> "I guess I'll try. BTW, the..." <- Yes, I saw this one too when I was trying that.
<dgilmore>
jhovold: what devices need the jsn/mbn files from under /lib/firmware/qcom/ to be in the initramfs if the qcom_q6v5_pas module is. I assume all of them
jglathe_x13s has joined #aarch64-laptops
<jglathe_x13s>
KieranBingham[m] new image just test "installed", uploading now (link should be the same)
<jglathe_x13s>
boot from nvme appears to be way more convenient
<dgilmore>
Jasper[m]: you just need the mbn files in the initrd and not the jsn ones
<Jasper[m]>
dgilmore: Alright, thanks!
<dgilmore>
and they can be compressed. no need to decompress them
<dgilmore>
the dracut devs have not tagged the 060 release that they just bumped fedora to. I am trying to figure out where the change was that pulled in the modules
<jglathe_x13s>
naah I'm consistent, topic was what works booting from USB-C, this is my odd image for this case.
<jglathe_x13s>
bringing up the X13s from scratch seems to be a bit of a challenge currently
<\[m]>
it does live boot too?
<jglathe_x13s>
yep
<\[m]>
ok good to know\
<jglathe_x13s>
and fetches the fw from the windows install if available, but will work regardless (linux-firmware has a pretty recent version, except for venus I guess)
<jglathe_x13s>
and danger, its rooted. so not secure, but fairly debuggable. ssh root access is enabled, pw FsecuritY!
KREYREN_oftc is now known as Kira
<konradybcio>
the linux-firmware.git firmwares are oooooold
<konradybcio>
windows gets updates every few weeks :/
<steev>
they can be downloaded from lenovo's site and extracted with innoextract
<konradybcio>
the windows and uefi rproc firmwares aren't the same iirc