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
Norbert011 has quit [Quit: bored]
Norbert011 has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
sally has quit [Quit: sally]
sally has joined #aarch64-laptops
alpernebbi has quit [Ping timeout: 480 seconds]
alpernebbi has joined #aarch64-laptops
<deathmist>
travmurav[m]: great work on https://github.com/TravMurav/dtbloader, I got it working but one question: any possibility to get it somehow loading a dtb based on kernel version after selecting an entry? i.e. from <esp>/dtbs/dtbs-6.12.0-rc7-0-generic/qcom/... where I had to copy it from to <esp>/dtbs/qcom/ right now
<deathmist>
it also replaces the usual systemd-boot menu with just the "Detected device" message unless I press ESC a few times it seems
<deathmist>
actually that stopped after I messed with the timeout settings in the menu now? ig smart dtb selection isn't too possible really minus some kinda glob search at most loading the one for latest kernel version maybe
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
<bamse>
kuruczgy[m]: yeah, then there's something else holding votes as well...
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
tobhe_ has joined #aarch64-laptops
_whitelogger_ has joined #aarch64-laptops
tobhe has quit [Ping timeout: 480 seconds]
_whitelogger_ has quit [Remote host closed the connection]
<travmurav[m]>
tobhe: steev re grub patch for drivers <- we talked a bit with Mate Kukri and they said they personally aren't opposed to the submission as-is, but secure-boot case will be more complicated with shim and friends (sadly seems that at some point they didn't hit reply-all and neither of us noticed, so part of the thread is off list) No one from grub team has replied with ack/nack it seems as of now :/
<travmurav[m]>
deathmist: this is actually a slightly non trivial question
<travmurav[m]>
i.e. dtbloader on it's own can't know what kernel you're going to boot, or even where you're placing your dtbs actually
<travmurav[m]>
so i.e. you may want to boot version x and it might misdetect (i.e. newer) version y
<travmurav[m]>
so as of now, dtbloader only has a set of fixed, generic lookup paths
<travmurav[m]>
deathmist: but ideally what would happen is like
<travmurav[m]>
dtbloader starts and installs some dtb and/or some configuration table that would contain canonical dtb name it detected ("qcom/foo.dtb"), then a bootloader starts, it realizes that it needs to "detect the device" somehow (i.e. we extend uapi blspec with "devicetree-dir" akin to u-boot extlinux), finds out that there is already a dtb/config table loaded, reads it to figure out canonical dtb name and overwrites that dtb with the one
<travmurav[m]>
it knows is needed from a dir, then calls dt-fixup protocol to let dtbloader finish it up
<travmurav[m]>
but in this case we already need cooperation from the bootloader
<travmurav[m]>
i.e. for sd-boot we need to extend the spec + implement, with grub probably similar situation
<travmurav[m]>
and all of this doesn't even scratch the secure-boot implications
<travmurav[m]>
since ideally dtb files should be signed somehow
<travmurav[m]>
deathmist: so we were loosely discussing that dtbloader tooling could also provide a sideband blob with dtb hashes, signed in uefi style and let either dtbloader(via protocol) or the bootloader to verify those
<travmurav[m]>
suddenly the scope of the problem is big big big and as of now neither people have even decided how exactly everyone should handle dtbs nor we (i think) have any practical use for SB since tpm is broken anyway
reedhhw[m] has joined #aarch64-laptops
<travmurav[m]>
I was thinking to prototype something on dtbloader side wrt both sideband signing and "canonical dtb name" configuration table but haven't got my hands to that somehow
<travmurav[m]>
tbh could also spend another weekend and write a bare minimum loader based on u-boot's extlinux.conf spec and create even more chaos
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
martiert has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
<tobhe> "don't set the brightness to 3855" <- Is it the same on T14s? 0-3850?
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
creemj has quit []
creemj has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
Caterpillar has joined #aarch64-laptops
martiert has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
<deathmist>
travmurav[m]: yeah this all really doesn't sound ideal for generic isos.. for the path thing I was thinking if I cannot find it from a fixed path it could maybe look under all of <esp>/dtbs/* and somehow determine the "latest one" to use, while that's not perfect it could be good enough at least in my case where the dtbs are already stored under
<deathmist>
<esp>/dtbs/dtbs-6.12.0-rc7-0-generic etc assuming ESP mounted as /boot
<deathmist>
maybe I'll try see if I could hack something together if it doesn't take too long
_whitelogger_ has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #aarch64-laptops
kalebris_ has joined #aarch64-laptops
kalebris has quit [Ping timeout: 480 seconds]
kalebris_ is now known as kalebris
<anonymix007[m]>
deathmist: multi-dt UKI support was recently merged into systemd and should be available in v257, but you may try it already.
<deathmist>
anonymix007[m]: ooh interesting, should it avoid the need for a user-configured dtb name somewhere or dtbloader?
<deathmist>
awesome, guess I'll switch gears and look into building systemd-boot v257-rc2 and go from there
<macc24>
oh finally
<macc24>
~~it's like carcinization with stuff becoming more similar to depthcharge~~
jkm has joined #aarch64-laptops
<deathmist>
anonymix007[m]: do I understand it right that you still need https://github.com/anonymix007/systemd-stub to actually do all the work and it's not possible with just what's merged in upstream systemd-boot itself?
<deathmist>
or was that the stop-gap solution until all the pieces got upstream?
<anonymix007[m]>
It's just a way to build system-stub without meson because, apparently, cross-compilation is an unsolved CS problem. You may use hwids/*.txt for now though, but I might have to convert these to JSON at some point.
<deathmist>
anonymix007[m]: hah, funnnily enough Void Linux + xbps-src still seems to have the best package cross-build support I've seen so far (with qemu as fallback helper for some packages) since they cross-build all supported non-x86 repos, and https://github.com/void-linux/void-packages/blob/master/srcpkgs/systemd-boot/template looks to cross-build too
<deathmist>
for me it was one of the reasons I eventually left arch for void actually since I mess with ARM-based stuff so much
<deathmist>
at least now I also have the option to do native ARM builds more or less as quickly as my desktop
<anonymix007[m]>
I'm still on arch because of aur. There are quite a few packages there which I need, i.e. openvpn3 and xorg-server-bug865 (it's insane that this is still an issue basically everywhere after 20 years)
<deathmist>
bedrock linux eh? ;)
<jkm>
Same here: Void Linux on ARM is a breeze - simpler and better than Arch - you don't need to bother with systemd and it just works :)
tobhe_ is now known as tobhe
<tobhe>
JensGlathe[m]: yes, 0-3850 on T14s
<tobhe>
I have played with brightness levels in the dt but haven't figured out a way to get it right with just that
<JensGlathe[m]>
well, fun. I guess this needs to be fixed in Gnome?
<deathmist>
right I should try the brightness patch soon as well, I'm on Plasma 6
<tobhe>
no, it isn't gnome
<tobhe>
you can reproduce it with brightnessctl too
<JensGlathe[m]>
yes that's true. Question is... workaround or fix?
<dgilmore>
travmurav[m]: in an ideal world the system firmware provides a DTB and we use it
<travmurav[m]>
yes
<travmurav[m]>
but the world is not ideal is it
<tobhe>
I think the question is: is this a bug in pwm-backlight or in qcom-spmi-lpg
<tobhe>
or just something that needs to be configured in the dt
<JensGlathe[m]>
I saw something in the Surface Pro 11 dump, looked like a dt, but with guids for the nodes and hardware identifiers
<tobhe>
the 4095 default limit comes from pwm-backlight
<JensGlathe[m]>
most consistent way would be to have min/max in the dt?
<dgilmore>
travmurav[m]: sadly it's not.
<tobhe>
you can do two brightness-levels for min max and then configure a reasonable amount of interpolation steps, like 1024
<tobhe>
but that still wrapped when I tried it
<tobhe>
it clearly looks like an overflow somewhere
<JensGlathe[m]>
Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml looks a bit like you could specify min / max
<tobhe>
brightness-levels = <0 3850> would have been my naive first guess
<deathmist>
for changes like this you should be able to directly edit the decompiled dtb after running it through dtc on-device, do the .dts edit and re-compile it back to dtb :p
<deathmist>
hm actually maybe not, I remember there was some regression with decompiled values
<JensGlathe[m]>
this levels curve is quadratic, its 5 levels it calculates with 2048 points each.
<JensGlathe[m]>
looks to me like we need to fix pwm_bl.c
_whitelogger_ has quit [Remote host closed the connection]
<robclark>
travmurav[m]: tbh it isn't all bad if dtbloader doesn't know how to load per-kernel-version dtb.. it kinda forces us to be more disciplined about treating dtb as abi. And I think it is mainly only problematic in early bringup stages (ie. dtbloader is a bit more for when a platform gets to the "just work" stage, but folks doing bringup know how to pick the correct dtb to load)
<travmurav[m]>
yeah I kinda agree that we should care about both-way-compatibility
<travmurav[m]>
(and tbh I believe it's mostly possible)
<travmurav[m]>
that's why one of the loose thoughts woudlv'e been to i.e. ship /esp/dtbloader/dtbs out-of-band (i.e. via fwupd)
_whitelogger_ has joined #aarch64-laptops
<travmurav[m]>
but then again, "platform bringup" feels to be a neverending churn at this point so probably still need to consider the usecase when we need kernel->dtb matching
<robclark>
right, a fwupd plugin that dumps latest and greatest dtbs into the ESP would be awesome
<robclark>
I guess one thought, perhaps it would be useful to mark some dt's as depending on CONFIG_STAGING during early bringup.. and fwupd only ships dtb's that don't depend on CONFIG_STAGING
<robclark>
(or CONFIG_STAGING_DTBS or something like that)
<travmurav[m]>
or just have some allowlist for "passed QA at some point" in whatever would build them xD
<robclark>
that way the folks doing bringup can signal when they thing a dt is stable and they are ready to treat any breakage as a bug
<robclark>
like, maybe there should be some tooling that could detect any dtb change other than addition/enabling new nodes
<tobhe>
looks like the pwm-backlight change breaks display brightness control on the T14s OLED model....
<macc24>
screen on and sleep exit both sound like they would be ran on bootup, as... the device powers on the display and exits low power state
<JensGlathe[m]>
Which means they have the other method via edp
<tobhe>
yes, and it did actually work before
<tobhe>
the way we currently enable the OLED is a hack anyway, I think the proper solution would be panel { compatible = "samsung,atna45af01", "samsung,atna33xc20"; ... } in the dtb
<JensGlathe[m]>
Separate dtbs
<JensGlathe[m]>
We‘re reaching new levels of fuckery
<tobhe>
but even more dtbs to pick from at boot time is also not ideal
<macc24>
JensGlathe[m]: > <@jglathe:matrix.org> Separate dtbs
<macc24>
> We‘re reaching new levels of fuckery
<macc24>
don't look at sc7180-trogdor-lazor-*.dtb
<tobhe>
the surface 7 also needs different dtbs depending on configuration
<JensGlathe[m]>
Similar issue with wcn6855 vs wcn7850 and powerseq
Norbert011 has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
I guess I will add a new parameter for pwm_bl as RFC and hack: max_brightness_duty_index with the value tested out for the config
<JensGlathe[m]>
I assume there is some maximum duty percentage in the pwm here, and its not 100%
Mary has quit [Quit: .]
Mary has joined #aarch64-laptops
<calebccff>
hey ya'll, anyone out there running box86 on X1E? Does this hardware lack armhf support? my memory is fuzzy and i can't find any good resource online
<JensGlathe[m]>
AFAIR no arm 32 bits
<calebccff>
ahh
<calebccff>
so only fex can work i guess
<tobhe>
yes, I have played portal via fex
<tobhe>
but there is a bug with the latest steam update
jkm has joined #aarch64-laptops
Norbert011 has joined #aarch64-laptops
Norbert011 is now known as Guest13
Guest13 has quit []
<JensGlathe[m]>
backlight is beginning to behave predictably. Tried 1000 levels, max duty cycle is 960. Tried 100 level, max duty cycle is 96.
_whitelogger_ has quit [Remote host closed the connection]
<macc24>
<calebccff> "so only fex can work i guess" <- yeah, i tried box86, forgot that arm32 in EL0 could be dropped and proceeded to be confused why it didn't work
_whitelogger_ has joined #aarch64-laptops
_whitelogger_ has quit [Remote host closed the connection]
<deathmist>
yikes that's actually very dissappointing to me if there's no way to get faster than qemu-user armv7 (Linux) execution, I wanted a fast machine for native ARM builds that could also do 32-bit :(
<robclark>
macc24, JensGlathe[m]: multiple SKUs with different dtb is pretty typical tbh.. for chromebooks, the bootloader reads some strapping pins to figure out what to use.. for windows laptops, _hopefully_ the DMI strings differ so dtbloader can pick the right one
<travmurav[m]>
I think I've seen some funny oem entries in DPP, like "keyboard type" so worst case could figure out whatever oem uses and use that too
<robclark>
re arm32, I suppose if someone was motivated enough they could write a fex-emu sort of thing for emulating arm32 under arm64
<tobhe>
robclark: I hope so too, I am not 100% convinced they actually do. Maybe we should start collecting dmidecode output in aarch64-laptops/build/misc too
<travmurav[m]>
so far my impressoin was that they're not too specific
<travmurav[m]>
seems like so far in my collection only some lenovo skus are meaningfully different, i.e. 21bx<->21by
<travmurav[m]>
yeah ^^ is the collection
<tobhe>
ah cool thx, i didn't know that one :)
<tobhe>
guess I could add an 21N2
Norbert011 has joined #aarch64-laptops
<JensGlathe[m]>
argh. @deathmist can you pull the brightness control to 100% without the screen going dark?
<JensGlathe[m]>
On Gnome 47 (Ubuntu 24.10) its going dark for me when going over 96%, almost regardless of granularity of the brightness levels. If pwm_bl gives back the 96% as maximum, the same happens at 96% of that (>92).
hightower2 has joined #aarch64-laptops
Caterpillar has quit [Quit: Konversation terminated!]