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
clover[m] has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
hightower3 has quit [Ping timeout: 480 seconds]
TangTang[m] has joined #aarch64-laptops
HellDuck[m] has joined #aarch64-laptops
hightower4 has quit [Ping timeout: 480 seconds]
ahoneybun[m] has joined #aarch64-laptops
strongtz[m] has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
AlekseiNosachev[m] has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
logan2611 has joined #aarch64-laptops
Timmy[m] has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
freekurt[m] has joined #aarch64-laptops
M9names[m] has joined #aarch64-laptops
sally has quit []
chrisl has joined #aarch64-laptops
kjm99[m] has joined #aarch64-laptops
matheustura[m] has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
angeloverlain[m] has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
dcavalca has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
JosDehaes[m] has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
travmurav[m] has joined #aarch64-laptops
noisycoil[m] has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
mltemev[m] has joined #aarch64-laptops
owen[m] has joined #aarch64-laptops
chapstikk[m] has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
Treibholz[m] has joined #aarch64-laptops
KieranBingham[m] has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
macc24 has joined #aarch64-laptops
Meti[m] has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
Leandro[m] has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
whiskey9 has joined #aarch64-laptops
Jasper[m] has joined #aarch64-laptops
WeetHet[m] has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
jdb[m] has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
tobhe has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
tobhe_ has quit [Ping timeout: 480 seconds]
genius1237[m] has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
osmoz[m] has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
Eighth_Doctor has joined #aarch64-laptops
sadan[m] has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
[UNAVAILABLEUSER][m] has joined #aarch64-laptops
valpackett has joined #aarch64-laptops
life00[m] has joined #aarch64-laptops
zaktur[m] has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<bamse>
deathmist: things are moving on the firmware front as well...
chrisl has joined #aarch64-laptops
whiskey9 has quit [Ping timeout: 480 seconds]
<bamse>
tobhe: what the PEP gives you is the ability to do power management from the OS (although only Windows) when the concepts in ACPI doesn't meet your needs
tobhe[m] has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<bamse>
tobhe: take the first functional/peripheral node from the x1e dtsi as an example - the qup/i2c controller...to operate that we need a suitable amount of power on cx, we need bunch of clocks and a few bus votes, we need the ability to scale these based on the requested peripheral clocks, and we need pinctrl to configure tlmm to connect the signals of the ip-block to the pads on the chip...
<bamse>
tobhe: at best it would be completely unmaintainable to describe this directly in acpi; so we need to design the whole thing (software) differently
smoorgborg[m] has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
Daanct12 has joined #aarch64-laptops
Danct12 has quit [Read error: Connection reset by peer]
chrisl has joined #aarch64-laptops
nirik has joined #aarch64-laptops
alexVinarskis[m] has joined #aarch64-laptops
<robclark>
that sounds like a diplomatic way to explain why PEP is a back door around ACPI limitations ;-)
shadowarrior[m] has joined #aarch64-laptops
<bamse>
robclark: :)
<bamse>
it's one way to tackle the problem...
<robclark>
now we just need to convince MS and other OEMs of the error of their ways ;-)
chrisl has quit [Ping timeout: 480 seconds]
bumble[m] has joined #aarch64-laptops
Tammieyem[m] has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
n0nfl3x[m] has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
mehdidjait[m] has joined #aarch64-laptops
blue_alex[m] has joined #aarch64-laptops
Badhri[m] has joined #aarch64-laptops
\[m] has joined #aarch64-laptops
McCak[m] has joined #aarch64-laptops
cenunix[m] has joined #aarch64-laptops
kuruczgy[m] has joined #aarch64-laptops
farchord has joined #aarch64-laptops
GurneyBuchanan[m] has joined #aarch64-laptops
Hugo[m]1 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]
eluks has quit [Remote host closed the connection]
eluks has joined #aarch64-laptops
jglathe_volterra has joined #aarch64-laptops
<travmurav[m]>
deathmist: robclark FWIW I'm getting more and more convinced that adding "devicetree-dir" into BLS is a good idea, then dtbloader could set a volatile efivar like DtbDir and sd-boot et al could read it and prepend dtbdir to it
<travmurav[m]>
like at first we can actually get all the "each kernel/boot option has it's own dtbs" to solve the wip kernels problem
<travmurav[m]>
(I actually changed dtbloader to not require loading dtb so one can use fixups alone and do UKI, but I still don't exactly like UKI for some reason lol)
<travmurav[m]>
but more interestingly, if we consider -el2.dtb
<travmurav[m]>
the distro tooling could copy all -el2.dtb into a separate dtbdir and rename them to canonical names, present the user with two boot options
<travmurav[m]>
and then it would "just work" with a generic image having el1 and el2 boot options
<travmurav[m]>
and lastly if you really hate dtbloader, can always just commit the DtbDir variable to NV storage
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<Treibholz[m]>
Has anyone managed, to convince the "Qualcomm Snapdragon X55 5G" modem in the X13s, to actually use 5G? Mine only wants to use 4G, as it is "preferred". And I can't change the preferrence.
<Treibholz[m]>
error: couldn't set current modes: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Failed: Failed: reloaded modes (allowed '3g, 4g, 5g' and preferred '4g') different to the requested ones (allowed '3g, 4g, 5g' and preferred '5g')'
chrisl has joined #aarch64-laptops
<Treibholz[m]>
I just rebooted and tested it on windows. There I get 5G... For some reason on linux 4G is "preferred" and 5G never used.
chrisl has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
Mine is using 5G
<JensGlathe[m]>
Vodafone net in Germany
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<deathmist>
bamse: I understand it to a degree but all these quirks combined so far only found on current Qualcomm-powered computers including X1E make them more like the existing locked down smartphone platforms, I practically "felt like at home" coming from already having dealt with mainline kernel on MSM8998/SDM845 Android phones and that *really* isn't a good thing lol
* travmurav[m]
wonders if it's worse since here one doesn't even have access to downstream linux to try and reverse engineer things to get things working beyond the timeframe where qcom sponsors it directly
chrisl has joined #aarch64-laptops
<deathmist>
travmurav[m]: for distros being able to do something similar to U-Boot fdtdir would be ideal, sounds like a plan
<travmurav[m]>
yeah u-boot fdtdir is the prior art I want to see in BLS
<sgerhold>
Treibholz[m]: It's the same for me, but even in "preferred 4g" state the access tech shown in the modem details is "lte, 5gnr". I'm not sure if it would display 5G only for 5G SA and not 5G NSA. On Windows I have "5G(NSA)" if you look in the modem details on the command prompt
<travmurav[m]>
and how it knows the name would be implementation detail - for sd-boot makes most sense to do a efivar
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
davidinux has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
ektor52 has joined #aarch64-laptops
ektor5 has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
hightower2 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]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
icecream95 has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
icecream95 has quit []
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
craftyguy has quit [Remote host closed the connection]
chrisl has joined #aarch64-laptops
craftyguy has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
Kobold[m] has joined #aarch64-laptops
<Kobold[m]>
Hi #_oftc_#aarch64-laptops:matrix.org : What is your recommended bootloader when trying to boot archarmlinux on an x13s? systemd-boot, grub as well as efistub installed, efistub even made the necessary boot entries, but ultimately boot failed as the laptop is unable to find the bootloader. If it helps, I am using ironrobins archisot to install from. released June 2024
<Jasper[m]>
Both should work fine, is there an exact error message you are seeing?
chrisl has quit [Ping timeout: 480 seconds]
<Kobold[m]>
unfortunately no, both install fine, efistub creates the EFI entries, but even if I chose this one, it fails silently. systemd-boot just fails silently, but no boot entry
<Kobold[m]>
trying instal with grub now
<Kobold[m]>
same ...... strange
<JensGlathe[m]>
secure boot on or sth?
<Kobold[m]>
Secure boot disabled, at least I am ok to boot the boot media
<Kobold[m]>
from usb
<JensGlathe[m]>
did you list the efi boot entries per chance
chrisl has joined #aarch64-laptops
<Kobold[m]>
jens: you mean check them in Bios setup? Just the one created by efistub and that's the first on the list
<JensGlathe[m]>
what does it try to boot then, bootaa64.efi?
<Kobold[m]>
not sure, let me reinstall once more using efistub and check on the system.
chrisl has quit [Ping timeout: 480 seconds]
<anthony25>
what do you mean by fails silently?
<anthony25>
it tries to boot, then reboots after a few seconds?
chrisl has joined #aarch64-laptops
<anthony25>
iirc someone here talked about the compression to use for the efistub, or it was failing to boot
chrisl has quit [Ping timeout: 480 seconds]
<JensGlathe[m]>
but this doesn't fail silently, usually
<bamse>
deathmist: well, given that we can't encode all the hardware controls directly in the dsdt, the alternative would be that we move it from pep to firmware...and then it's going to be even more locked down...but you won't notice
<bamse>
travmurav[m]: not sure if i understand your proposal, but i don't fancy mechanisms where the generic bootloader somehow is expected to figure out which dtb to load...no matter how you do it, it won't scale
<travmurav[m]>
well of course I don't want to duplicate the detection in each bootloader, my plan is to pass the file name into the bootloader using efivars, but we still need bootloaders to know where to look for a dir with dtbs, to append the name to it
<bamse>
ahh...yeah the mechanism of loading a given dtb based on efi variable i'm onboard with... so you're saying the problem is that it's a relative path?
<travmurav[m]>
bamse: well it just needs to be implemented, yes
<travmurav[m]>
as in
<travmurav[m]>
right now sd-boot doesn't have a mechanism, so if I care about sd-boot, I need to update bootloader spec
<travmurav[m]>
grub could just read efivars in the script
<travmurav[m]>
and on the other side, the efivar could be set by the user or by dtbloder or by whatever
<travmurav[m]>
so i.e. u-boot's extlinux has "devicetree-dir /boot/dtbs" and it would resolve the dtb path to "/boot/dtbs/whatever.dtb" (and the whatever.dtb is somehow detected)
<travmurav[m]>
and I think for grub it could be scripted, but for sd-boot it needs a spec update
chrisl has joined #aarch64-laptops
<tobhe[m]>
fwiw from a secure boot point of view the trend of bundling kernel + dtbs in a single file is really a lot simpler to deal with than a /boot/dtbs directory because of how shim works
<tobhe[m]>
because shim can really only verify EFI binaries for reasons
<travmurav[m]>
well doesn't stop uki-stub from using same efivar
<tobhe[m]>
well it doesn't have to be bundled with the kernel, could be any bootloader really. but I guess the kernel makes sense because that's where they come from
<tobhe[m]>
indeed
<travmurav[m]>
but if someone really want to, I don't see a problem of using a PE as a signed container for hashes
<tobhe[m]>
that could work too in theory
<\[m]>
Treibholz I played a bit with modems to make a hotspot, my experience is that it's best to use the proprietary binaries and ask to the vendor directly for firmware update
<bamse>
travmurav[m]: annoying that the dtb isn't specified by absolute path...but i guess that comes with its own hurdles
<bamse>
tobhe[m]: preferrably the vendor should make sure that uefi provides us with a proper hardware description
<travmurav[m]>
Well the problem is that we can have like /boot/dtbs-6.15 and /boot/dtbs-6.16 (ir what i care more about /boot/dtbs and /boot/dtbs-el2)
<travmurav[m]>
So it would be helpful for a boot option to select the prefix and $something to provide a canonical suffix
<Jasper[m]>
@bamse iirc there's some UUID structure winupdate uses to ask for device specific updates, built from data you could normally fetch from dmidecode
<\[m]>
and don't use mm in parallel btw
<Jasper[m]>
I think @travmurav was already making a list of devices with similar indo
<Jasper[m]>
*info
<travmurav[m]>
And I mean of course it would be perfect if vendors were just including dtb file from latest mainline linux, but that doesnt happen xD
<bamse>
Jasper[m]: problem is that that structure doesn't capture all the variables
<travmurav[m]>
Yeah we need more code for oled/ips etc
<Kobold[m]>
<anthony25> "it tries to boot, then reboots..." <- It does not boot, just enters bios and sits there as it can
<Kobold[m]>
t find anything to boot from
<bamse>
travmurav[m]: well, your problem wouldn't be addressed regardless, because you don't want the _one_ devicetree anyways
<bamse>
travmurav[m]: oled/ips, touchpad second source etc
chrisl has quit [Ping timeout: 480 seconds]
<bamse>
travmurav[m]: not to speak about the fact that you in some cases need to adjust things based on which revision of the soc you have...or which revision of the pcb you have
<anthony25>
And systemd-boot without efistub works?
<Kobold[m]>
not yet
<travmurav[m]>
bamse: well, in the end, I was designing around that from the start, with dtbloader's highligt feature being dt-fixup protocol - we already handle mac addresses, doesnt get more granular than that xD
<JensGlathe[m]>
Purchasing power of the Linux user cohort appears to be too smal to be even considered
<travmurav[m]>
And yes I know it is a nightmare to write heuristic for everything
<travmurav[m]>
But I really see nothing better apart from someone just implementing all the PEP stuff, including board files for aeob stuff
<bamse>
travmurav[m]: yeah, you have to implement every device-specific selection criteria somewhere...and if that isn't done in the device-specific uefi...
<bamse>
travmurav[m]: this doesn't have anything to do with PEP
<JensGlathe[m]>
its about hardware discovery
<travmurav[m]>
In the end, I just dont like the status quo in many places where the user is expected to manually mess with dtbs just to get anything working
<bamse>
travmurav[m]: there are two mechanisms at play in windows for this, vendor checks are implemented in dsdt...and configuration in the device drivers (presumably some configuration of the pep driver as well)
<bamse>
travmurav[m]: i don't like that either... we can never scale this to a any userbase without a better solution than what we have
chrisl has joined #aarch64-laptops
<travmurav[m]>
bamse: yes, that's why im trying ti at least do /something/ and the time will tell how wrong I was
<valpackett>
..so why can't distros just ship either dtbloader as is, or UKIs with dtbs matched to hwids?
<bamse>
travmurav[m]: but while i see the efi variables to be very convenient, i don't think it will have any real impact on the situation
<travmurav[m]>
But it upsets me when some people just sit down, say "dtbs bad, we want it to just work and do nothing ourselves" and... do nothing
<valpackett>
(pmOS ships dtbloader for Trailblazer, but we should make a "normal daily user" generic qcom device already)
<travmurav[m]>
I can't do anything for those people
<tobhe[m]>
Val Packett: UKIs come with some quite opinionated architectural limitations that break a bunch of packages on "normal" distros today
<travmurav[m]>
Val Packett: they can
<tobhe[m]>
anything shipping a initramfs-tools script or hook in debian/Ubuntu today for example
<bamse>
travmurav[m]: i agree with you there
<valpackett>
yeah, these should use dtbloader (I guess grub not doing the ...../drivers thing is the obstacle for those using grub?)
<bamse>
valpackett: you can't base your selection on hwids...because it's not descriptive enough
<travmurav[m]>
so basically, at this point I'm not trying to make a "perfect solution for everyone" since I don't see many people/distributions to care, yet I want to create a solution /I/ can stand behind, and provide a reference use for it at least in pmOS, which is why pmOS already more or less boots on things ootb, even if it's not perfect, noone complained yet
<travmurav[m]>
same for ubuntu with strcmp scripts I guess
<bamse>
travmurav[m]: that's fair. the vendors needs to fix this problem from the start if we're to have the proper solution
<tobhe[m]>
yeah, my solution is messy but the goal was that people can use it without having to care too much about dtbs and that works for the moment
<travmurav[m]>
yep, yet I'm a deep pessimist and tbh I don't see this being fixed in at least few more hw generations, definitely not for any already existing devices - yet sitting and crying is not something I like to do, at least not in case of software development xD xD
<bamse>
travmurav[m]: that said, we keep running into the questions about backwards/forwards compatibility...so one open question i have is if the vendors does implement devicetree properly...will it actually work to ship a version of the dtb in "bios"
<travmurav[m]>
I really think it could, even as a heuristic to pick a compatible value from it
<bamse>
travmurav[m]: i think so too...and if not, then dt won't work beyond highly integrated embedded devices...
<robclark>
it will be fun seeing the kernel have dt fixup quirks like we have for acpi systems ;-)
<bamse>
travmurav[m]: but regarding the hw generations...that is true for windows systems, as they naturally won't come with dt...but for naturally dt-based systems there's nothing preventing us from having solved this already
<tobhe[m]>
it works for android, chromeos and apple doesn't it?
<travmurav[m]>
yeah but I guess for embedded dt-centric systems it's not often a concern to boot a general purpose OS yet
<bamse>
tobhe[m]: android and chromeos bundles dt with the kernel in one binary
<travmurav[m]>
I think some servery things actually ship dtbs
chrisl has quit [Ping timeout: 480 seconds]
<valpackett>
laptops in general kind of are highly integrated, heh
<robclark>
it works for CrOS because the "vendor" is working upstream and the fw takes care to pick the correct dtb (based on strapping pins, etc)
<travmurav[m]>
as in, most server-y/workstation things that care about linux conform to sbbr of course and they generally "just work" anyway
<travmurav[m]>
but I think there were few that had dtb as an option
<travmurav[m]>
in firmware
<bamse>
travmurav[m]: conceptually you can do it with the current generation "qualcomm linux" releases...just that the bundled dtbs still are based on some downstream bindings...but other than that it works fine
<travmurav[m]>
and as long as that dtb is conformant to upstream bindings contracts, it should just work I think
<travmurav[m]>
yeah, the main problem is conforming to the bindings I guess
<bamse>
valpackett: not in that sense, but rather the same person building the bootloader, os-loader, and the OS
<valpackett>
travmurav: yeah.. upstream edk2 for marvell a8040 does have an acpi/dtb selector in the setup, maaybe the nxp lx2160 too, i guess the new trendy CIX soc might have that too
<bamse>
travmurav[m]: and that turns into the problem that we don't have bindings to fully describe the system yet
<travmurav[m]>
yeah
<valpackett>
bamse: well, in our linux distro case the os-loader at least is built by the distro..
<travmurav[m]>
then again, how much formal bindings there are for acpi :P
<bamse>
valpackett: right, and that distro isn't bound to a specific board...i.e. those two are not tightly integrated
<travmurav[m]>
this whole problem space is really deep and hard
<bamse>
travmurav[m]: yeah, i was "surprised" to learn how much better dt is in that regard (bindings/documentation)
<konradybcio>
well, put simply, the /accessible/ hardware outgrew the software :p
<valpackett>
bamse: sure, but it's "bound" to a giant set of boards that have been worked on, which is kiiiinda how it's always been with PCs..
<travmurav[m]>
bamse: I think it's linux influence - with acpi and windows centric approach, each vendor is allowed to just do whatever - they ship acpi, they ship drivers and it "works" with some PNP id downloading a driver, with mainline we actually write a spec
<bamse>
konradybcio: hehe, right we're also just considering interfacing with a subset of the hardware :)
<valpackett>
..the only difference from x86 is that x86 is so homogenous and de-facto-standardized-mostly-ish which helped the illusion of "arbitrary thing supported"
chrisl has joined #aarch64-laptops
<konradybcio>
"standardized" is one way to describe the x86 world ;)
<bamse>
well, question is how standard it is behind those standard firmware interfaces
<valpackett>
funnily enough qcom did give us the same kind of "standardized baseline" with acpi that e.g. BSDs can boot with PCIe+USB+I2C+.. working
<valpackett>
but linux throws the baby out with the bathwater
<bamse>
valpackett: no it's not "working"
<konradybcio>
following on the intel comparison, you won't get a whole lot of battery life or performance on the BSDs..
* travmurav[m]
remembers bsd hardcoding lookup tables for interrupts on gpios
<bamse>
valpackett: we had the same level of support in linux 4-5 years ago, but we abandoned it, because while you can get some life out of the system...you don't get a working system...and there's no path from proof of concept to a functional system
<tobhe[m]>
Not "working" but enough to get through the installer
<bamse>
tobhe[m]: yeah, we did that for sdm850, sc8180x...
<bamse>
tobhe[m]: but it wasn't useful beyond that, so we focused our efforts on making a usable system instead
<valpackett>
was there *really* no path for layering more support on top of acpi though or was it a "let's do it the way we've done it before" thing :D
chrisl has quit [Ping timeout: 480 seconds]
<konradybcio>
unfortunately, that is precisely the case
<konradybcio>
unless we want to throw out the advancements of the past 15 years and go back to boardfiles
<bylaws>
robclark: forcing zink for xwayland seems to have fixed it fwiw
<bylaws>
Not sure if that is particularly useful for narrowing things down
<robclark>
not really
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<bamse>
valpackett: it certainly helped (both ways) to use the same model as mobile and iot...but no, we would have had to amend the information and mechanisms provided by acpi with board files and a bunch of custom things
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<valpackett>
re: HWIDs not being specific, would be great to get rid of -oled -lcd dtbs in favor of some kind of dynamic "this pwm node for that eDP panel ID" inside of the one dt
<valpackett>
i just realized that it wouldn't be so wild and unimaginable since we do have e.g. speedbins being conditional on hw fuses
<valpackett>
OPPs being conditional on speedbins read from hw fuses, i mean
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
davidinux has quit [Quit: WeeChat 4.5.1]
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<kuruczgy>
So I bisected my EL2 boot issue to 428f95f41f302 "arm64: dts: qcom: x1e80100: Add PCIe IOMMU"
<kuruczgy>
I have no idea why adding a `status = "reserved";` node can suddenly break things though.
<kuruczgy>
Anyway, switching to the `-el2.dtb` that's now upstream works fine, so I will just do that.
<kuruczgy>
travmurav: I guess the overlay should be removed from the slbounce repo, if it's broken anyway. (Someone else should also confirm though.)
<kuruczgy>
deathmist: ^ see my results for the EL2 issue above, in case they are helpful
Kelsar has quit [Ping timeout: 480 seconds]
<travmurav[m]>
kuruczgy: oh yeah you want to use upstream overlays/el2 dtbs
<travmurav[m]>
on 6.16
<travmurav[m]>
I think I've documented it in slbounce readme
<travmurav[m]>
but decided to keep old overlays for people who still use older kernels for a bit
chrisl has joined #aarch64-laptops
<travmurav[m]>
kuruczgy: reserved broke it probably beacuse the overlay never overriden it to okay
<travmurav[m]>
so the pcie iommu was still disabled
<travmurav[m]>
(and thus the nvme drive couldnt' DMA)
<kuruczgy>
travmurav[m]: the readme doesn't say that you "have to" use the upstream dtbo, and that the older ones are suddenly broken
<travmurav[m]>
yeah I guess, sorry
<kuruczgy>
but anyway, I might be the only person out there with this exact issue so probably not a big impact :)
<travmurav[m]>
I just thought people would immediately switch to pre-made upstream dtbs xD
Kelsar has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<deathmist>
kuruczgy: I did the overlay on 6.15 and with 6.16 already was using the upstream -el2 dtb already, maybe the adsp lite patch magically will make stuff work properly we'll see ig
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<Treibholz[m]>
Jens Glathe: t-mobile (congstar) in Germany here... I also have a 1&1 SIM (with Vodafone National roaming) laying around somewhere at home... maybe I'll try that.
<JensGlathe[m]>
Vodafone, at least, assigns bandwidth by underlying contract. Maybe this is the reason.
<Treibholz[m]>
<\[m]> "Treibholz I played a bit with..." <- Soi I should ask Qualcomm directly for firmware-udates?
<Treibholz[m]>
Jens Glathe: I don't care for the bandwidth, but 4G reception gets worse and worse, while 5G gets better. So if my modem doesn't connect to 5G, my general connectivity will decrease.
chrisl has joined #aarch64-laptops
<JensGlathe[m]>
Do prepaid cards (like congstar sort of is) get 5G?
<Treibholz[m]>
Jens Glathe: it's not a prepaid contract and yes, it works on my android phone and on windows.
<JensGlathe[m]>
I mean I could try and put a congstar card in, wouldn't be surprised if it gives 4G only
<Treibholz[m]>
Jens Glathe: not all congstar contracts have 5G, but I booked the 5G option, just to test if 5G works :-)
<JensGlathe[m]>
argh no idea
<Treibholz[m]>
Jens Glathe: so ` mmcli -m 1 | grep 'current: allowed'` says ` 3g, 4g, 5g; preferred: 5g'? (maybe your modem ist not "1", but "0" or something else...)
<JensGlathe[m]>
lmc
<Treibholz[m]>
I mean, maybe just NetworkManager is lying, when it says "LTE"