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
mbuhl has quit [Remote host closed the connection]
mbuhl has joined #aarch64-laptops
hexdump02 has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
davidinux has quit [Read error: Connection reset by peer]
davidinux has joined #aarch64-laptops
davidinux has quit [Read error: Connection reset by peer]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
tobhe has joined #aarch64-laptops
tobhe_ has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
eluks has quit [Remote host closed the connection]
eluks has joined #aarch64-laptops
kalebris_ has joined #aarch64-laptops
kalebris has quit [Ping timeout: 480 seconds]
kalebris_ is now known as kalebris
jhovold has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
davidinux has joined #aarch64-laptops
srinik has joined #aarch64-laptops
srinik has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
srinik has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
exeat has joined #aarch64-laptops
exeat has quit [Remote host closed the connection]
<robclark>
anthony25: thx.. what compositor are you using?
<anthony25>
hyprland
<anthony25>
I can test if it happens on sway too
<robclark>
ok, I do have hyprland installed.. but not what I normally use
<robclark>
fyi akhilpo ^^^
chrisl has quit [Ping timeout: 480 seconds]
<anthony25>
robclark: but it might be specific to my setup, the freeze happens always at the same time, when hyprland and my startup-apps start
<anthony25>
then there's no problem
<robclark>
if you just start hyprland but nothing else, does it still freeze? If not could you narrow down which app?
<anthony25>
that's why I was (wrongly) suspecting that it was wifi related, because it happens at the same moment my wifi connects and network manager prints a notification
<anthony25>
robclark: sure, I can try
<robclark>
if it is something power related, I guess I wouldn't rule out wifi or other things causing a power spike or something weird.. you could try disabling wifi to rule that out, perhaps?
<anthony25>
and like I wrote in the patch thread, if I keep moving the cursor, it doesn't happen
<anthony25>
so I was suspecting the opposite, like the gpu going to a deep state for a moment
<anthony25>
I'll try this later and keep you updated (and once I narrow it down, give more info in the patch thread)
<robclark>
idk how cursor movement is related, tbh.. that seems weird.. but thx for trying to help narrow this down
<anthony25>
I thought that the cursor movement could force some gpu activity
<robclark>
it _might_ but I assume hyprland is just using display cursor plane
<anthony25>
another thing: I expose explicit sync in the driver, but I don't think it changes anything
<anthony25>
(mesa 25.0, so it shouldn't be an issue, from what I understood)
<robclark>
ok.. I've been running w/ explicit sync enabled for a while now
<robclark>
yeah 25.0 should be ok
chrisl has joined #aarch64-laptops
tudorel has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
ungeskriptet_ has quit [Remote host closed the connection]
ungeskriptet has joined #aarch64-laptops
hellfire7734club[m] has joined #aarch64-laptops
srinik has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
SpieringsAE has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
SpieringsAE has quit [Quit: SpieringsAE]
srinik has joined #aarch64-laptops
xyzabc has quit [Remote host closed the connection]
chrisl has joined #aarch64-laptops
<akhilpo>
anthony25, could you try updating the spinor images to the latest and greatest? I am not sure where you can download those images and flashing tools for commercial devices.
<akhilpo>
bamse, do you have any idea?
tudorel has quit [Quit: WeeChat 4.3.1]
<robclark>
I assume qdl doesn't work for commercial devices, if that is what you mean?
chrisl has quit [Ping timeout: 480 seconds]
<smoorgborg[m]>
Jens Glathe: When installing the 6.14-rc7.1 kernel my Ubuntu says "Installing .... lenovo-thinkpad-t14s.tdb into /boot/...." picking the non-oled version over the oled one. Is there something that can set preferred variant or how is this supposed to work?
<anthony25>
akhilpo: you mean the firmwares?
<JensGlathe[m]>
I actually don't know. I would suggest you pick the right one.
<anthony25>
there was a bios update from lenovo recently, I don't know if it's the one that is supposed to add the qualcomm signatures in firmware loading (instead of currently only accepting lenovo signatures)
<robclark>
the gmu fw isn't signed, fwiw
<robclark>
anthony25: could you confirm which kernel branch you are on
<anthony25>
jhovold's rc7
<robclark>
(msm-next should have the correct version of the ACD patch.. but gitlab.fd.o is down this week for migration)
<tobhe>
smoorgborg[m]: JensGlathe[m]: Looks liike we can't actually. impossible to automatically indentify which device we are running on at this point
<tobhe>
they report the same smbios info
<robclark>
can DtbLoader look at the ACPI tables?
<JensGlathe[m]>
ho abot a marker file that represents the installed one
<travmurav[m]>
why not xD
<travmurav[m]>
there is no interpreter in the uefi package but simple lookups shouldn't be too hard
<anthony25>
robclark: ha, because I didn't see a more up-to-date version on the linux-msm mailing list
<anthony25>
the latest I saw was v4
<travmurav[m]>
and anything is possible if we vendor in acpica, but that's a bit lame lol
f_[m] is now known as OLD|f_[m]
<robclark>
travmurav[m]: idk if the newer qc things still have it.. but in the past there was some xml blob in acpi that had all the panel info
<JensGlathe[m]>
yeah they have it
<travmurav[m]>
oh yeah I think it's still there but I think for new things it just says "edp"
<JensGlathe[m]>
several variants (all of the FRU parts I guess)
<anthony25>
robclark: if you have the patches, feel free to upload it to me (or send it by email) and I can test them
<travmurav[m]>
I've recently discussed somewhere else that for t14s there is a structure in ram that may (!) store the panel type so parsing just a bit of aml to find the struct base address could be enough
<robclark>
heheh, or just randomly pick the dtb at boot time, half the time it will work ;-)
<bamse>
akhilpo: the spinor firmware is oem signed, so it would have to be provided by each oem...and generally they don't provide the related signed programmer
<travmurav[m]>
but I also wonder if the customizations like this could be placed in dpp thingie like mac addresses and windows activation key are
<travmurav[m]>
but not sure if it's there for x1e
OLD|f_[m] is now known as f_[m]|OLD
<travmurav[m]>
FWIW my approach to dtbloader always assumed that everything is a total mess and it'd be impossible to differentiate devices without custom matching code, and so far lol don't see how that was wrong
<travmurav[m]>
but the sad part is that I still have an impression that there is not much interest in it, since most people would just hardcode their working dtb name and not bother
<travmurav[m]>
I think there were some discussions @ Linaro on fixing dtb selection some other way
<akhilpo>
anthony25, I guess spinor images might be called bios firmware in Windows world? Not sure though. Can you at least check the current version of your bios? Probably, Rob can compare it with his device's bios version.
<tobhe>
or worse, hack similar logic into a grub cfg
<JensGlathe[m]>
generic solutions are hard
<tobhe>
travmurav[m]: there was a fosdem talk from linaro
<travmurav[m]>
yes, I think there is another one planned at Linaro Connect
<travmurav[m]>
but I don't know anything about the details
<tobhe>
and systemd kind of adopted your approach minus the flexibility to do custom matching
<travmurav[m]>
but well, my general thought is that implementing matching tied to some specific loader/component ignores rest of the ecosystem (i.e. if you fix grub, you ignore sd-boot, if you fix sd-boot, you ignore freebsd, if you fix freebsd..._
<anthony25>
akhilpo: sure, I applied the latest bios update a few days ago, but I had the issue with Bios v1.53, Firmware Revision 1.60
<travmurav[m]>
there are many people at this problem, everyone with their own values and constraints so it gets extra complicated xD
<anthony25>
nothing changed with the latest bios, but I'll check the version too
<travmurav[m]>
exhasturbated with the problem being "one time" for a person booting first time, and once they script to fix it, they solved it for themselves, so for most people there is no investment on a more general fix
<tobhe>
travmurav[m]: otoh introducing an entirely new element in the boot chain seems problematic for getting UEFI secure boot working at some point
<smoorgborg[m]>
Uhhhhm, so there's the lcd variant t14s.dtb and the t14s-oled.dtb, so do I just push the oled variant on top of the non-oled name in /boot? How does the kernel chose what dtb to load, is that burnt into the kernel itself?
<robclark>
anthony25: I went back and double checked, v4 of the ACD series still has a bug.. idk if akhilpo has sent a newer version.. I'm using a locally fixed up patch:
<travmurav[m]>
but well, getting back to acpi, if what I've discussed is true, parsing out base address and the layout of that struct would be one weekend project even without vendoring in a proper acpi interpreter I think
<travmurav[m]>
tobhe: well I'd argue the SB problem applies to everything: you need to sign custom grub, custom sd-boot, custom dtb packages...
<travmurav[m]>
like, does your grub hack verify dtb hashes? xD
<tobhe>
right, but everyone already signs their custom grub
<tobhe>
it doesn't at this point no
<travmurav[m]>
so why not just i.e. sign dtbloader.efi and dtbsignatures.efi with the same distro key then? xD
<travmurav[m]>
I guess not sure if the shim can check it properly as of today
<tobhe>
because as I understand our bootloader people there are agreements in place on what can be signed
<tobhe>
and shim can only verify PE binaries
<anthony25>
robclark: you use it in combination with the v4 ACD series?
<tobhe>
and hardcodes grub
<anthony25>
thanks a lot for the patch, btw
<travmurav[m]>
well dtbloader is PE, and dtbhashes.efi would also be PE, just with no code xD
<travmurav[m]>
so the only question is whether grub can call shim's verification code to check few extra PEs I think
<robclark>
anthony25: it replaces the (IIRC) first patch
<robclark>
see the comment from Neil on that patch
<travmurav[m]>
(but it's very fair to say that I'm not familiar with SB and may easily miss the greater picture)
<anthony25>
ha ok, perfect
<tobhe>
and whether the authority would be ok with signing dtbloader as a payload
<tobhe>
but I can indeed forward that question
<travmurav[m]>
I mean, if the distro actually "audits" (at least takes responsibility for compiling and signing) the package, I fail to see how dtbloader is different from grub in that case
<travmurav[m]>
inb4 it's fine if dtbloader is just vendored in into grub
<bamse>
travmurav[m]: is there no sign of the panel/backlight selection in the dsdt?
<travmurav[m]>
I think the xml says backligth type (pwm/pmic wled/ etc) and mipi init sequences but I think it's not guaranteed it'd have real edid for edp
<bamse>
travmurav[m]: for the touchpanel on x13s i remember lenovo reading a byte from EC and having _STA enable the appropriate node based on this
<travmurav[m]>
there was an old doc for the xml format for db410c
<tobhe>
technically I don't disagree at all. funnily bundling it would indeed probably be easier to argue for
<bamse>
travmurav[m]: right, but didn't we finally give up on most of that?
<travmurav[m]>
oh, if you mean wrt t14s, as I was told, there is a defined memory region where some bytes are set that define which panel is there
<travmurav[m]>
so like acpi has struct layout + base address ( which I assume is patched in at runtime)
<travmurav[m]>
and reading (base)-> panel_type then decoding the enum might be enough to detect which panel is there
<bamse>
travmurav[m]: but are those written by the boot code? on x13s it was the DSDT itself that populated this information
<bamse>
i.e. you had to boot the OS for that data to be populated
<bamse>
boot the OS with the DSDT
<travmurav[m]>
I'd assume it's in ram when the os boots, but I don't have the hw to check myself
<bamse>
travmurav[m]: as i said, on x13s they read from EC and store in a table, then in a variety of _STA etc they check that table... but might have changed
<travmurav[m]>
(the struct is "SB/MNVS" in t14s dsdt.dsl if you're wondering)
<travmurav[m]>
and the field, as I was told, is "VPID"
<bamse>
but seems to me that the way you'd have to do dtb selection is to figure out which device you're on, and then run some device-specific code to figure out the sku variations within that and then load the appropriate dtb
<travmurav[m]>
ah yeah, it picks the xml of the panel based on VPID
<travmurav[m]>
yes, if I was adding it to dtbloader, I'd match on DMI CHIDS then parse out that SB/MNVS/VPID to pick
<bamse>
but the sb/mnvs/vpid is lenovo-specific, right?
<travmurav[m]>
I think so, t14s specific I guess
<bamse>
yeah, even so
<travmurav[m]>
so we'd need different hacks for each device like this
<bamse>
yeah :(
<bamse>
until we fix the problem
<bamse>
a different "we"
<JensGlathe[m]>
not only. Lenovo Thinkbook has the same, different panels
<bamse>
JensGlathe[m]: that doesn't surprise me, it makes sense for Lenovo to share their solution across different products
<bamse>
so it's probably not M*N custom functions that we need
<travmurav[m]>
I guess not helpful but eh perhaps they just don't use those xmls fully
<travmurav[m]>
but I'm reading the xml using the 8-wide hexdump thing so I might've easily missed some field lol
<JensGlathe[m]>
one is integrated backlight control, the other is pwm
<travmurav[m]>
I guess if someone wants to try dumping 8 bytes at (0xD6CF5018 + 0xF14 + 0x4b0) on t14s and compare between panels
<travmurav[m]>
(I hope I calculated this correctly)
<travmurav[m]>
and this would be only t14s obviously
<travmurav[m]>
dmem d6cf63dc 8 I guess
krei-se has quit [Read error: Connection reset by peer]
<travmurav[m]>
in uefi shell
<bamse>
"it's in the pmic!!!!"
<bamse>
good thing i only have 12 of those
<JensGlathe[m]>
pmk8550
<JensGlathe[m]>
and pmc8380_3 for the gpios, but apparently not on the Thinkbook
krei-se has joined #aarch64-laptops
<bamse>
i need to go talk to the team ask why it's not a _BCM() call
chrisl has joined #aarch64-laptops
krei-se- has joined #aarch64-laptops
krei-se has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
krei-se has joined #aarch64-laptops
krei-se- has quit [Ping timeout: 480 seconds]
krei-se- has joined #aarch64-laptops
krei-se has quit [Ping timeout: 480 seconds]
krei-se has joined #aarch64-laptops
krei-se- has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<anonymix007[m]>
travmurav: I recently tried reading EDID from UEFI and failed miserably. Can you also give it a try? I guess this would be the only sane way
Italiana22 has joined #aarch64-laptops
<smoorgborg[m]>
i can do dumps on my t14s oled if that helps, not sure how to end up in efi shell though
Italiana22 has quit [Remote host closed the connection]
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<robclark>
smoorgborg[m]: if you have a prebuilt shell.efi you can copy it over (after making a backup) bootaa64.efi
<anthony25>
robclark: I realized that I had already this ACD patch, it was just split in 2 in the series
<robclark>
ahh, right the fixup is squashed in the wrong place
<anthony25>
but I had several merge conflicts with 6.14-rc, so I maybe did a mistake somewhere
<anthony25>
I'll try a fresh merge
<anthony25>
I chatted with akhilpo, I tried to enable msm.disable_acd, and the freezes still happen
<robclark>
huh, weird.. well when gitlab.fd.o is back from datacenter migration I'll push my current working branch
<anthony25>
thanks!
<robclark>
oh.. hmm, gitlab.fd.o is kinda back.. maybe sorta?
<Jasper[m]>
Ye
tudorel has quit [Quit: WeeChat 4.3.1]
chrisl has quit [Ping timeout: 480 seconds]
srinik has quit [Ping timeout: 480 seconds]
<tobhe>
so it looks like a lot of people are still having ath12k issues causing blue screen crashes
<tobhe>
unfortunately I can't reproduce it locally
<JensGlathe[m]>
I can force the ath12k null-pointer deref on the tb16, by trying to associate with another network
<JensGlathe[m]>
Box is practcally unusable afterwards
<tobhe>
it seems that there are a bunch of null deref fixes on the ath12k ml, have you tried any of those?
<JensGlathe[m]>
no, should take a look
krei-se- has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
ungeskriptet has quit [Remote host closed the connection]
krei-se has quit [Ping timeout: 480 seconds]
ungeskriptet has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #aarch64-laptops
jhovold has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
hexdump01 has quit []
hexdump0815 has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
bibikski has joined #aarch64-laptops
<apple-corps[m]>
Does anyone know if it's possible to set the linux partition as the default boot device for my Asus Vivobook ? Unfortunately I don't see the option in the "bios". One annoyance is that I need to hit the esc key at boot. And for whatever reason this doesn't seem to invoke the boot "partition" selection everytime. Then as a user I need to go through sometimes multiple boots to Windows before I can start linux. I haven't yet
<apple-corps[m]>
removed Windows but my preference is to work with linux.
chrisl has joined #aarch64-laptops
<bamse>
apple-corps[m]: yes, you can reconfigure the boot order to load your grub/systemd-boot by default...either manually using bcfg from efi shell or using efibootmgr from within linux
<apple-corps[m]>
I will try to look that up. I am not sure how to get to the efi shell. I can look up the efibootmgr...
<apple-corps[m]>
thanks
<bamse>
if you're running grub, grub-install should take care of it for you (by invoking efibootmgr)
<apple-corps[m]>
Grub doesn't load by default. I need to hit esc and select the boot device which then invokes grub. Otherwise by default windows starts....
<bamse>
that boot order seems to meet the behavior you're describing (default into windows)
<bamse>
so i guess "efibootmgr -o 2" should do the trick...
<apple-corps[m]>
I just set the order. That was easy, thanks. sudo efibootmgr --bootorder 0000,0002,0001
<bibikski>
bamse: I fixed my mistake for device tree. Got passed the EFI boot part and it started to load the kernel. Then.... darkness. I wanna assume it could be correlated to the oled, I know I saw a bit of convo about that flying around here
<bamse>
bibikski: yeah, i unfortunately don't know the test-status of the oled, patches looked good so i merged them...
<steev>
sorry :(
<steev>
if it helps any, i've at least generated a kali image
<steev>
but our release hasn't gone out yet so still can't switch to the t14s
cyrinux has quit []
cyrinux has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<steev>
bamse: re: your flattened usb patches, what should be done to test them? just make sure that usb still works?