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
<kuruczgy[m]>
Well I found 6 tcblaunch.exes with 5 different hashes... But I guess the one in /Windows/System32/tcblaunch.exe is the one I should try first. (sha256 is 5dfcd0253b6ee99499ab33cac221e8a9cea47f3fdf6d4e11de9a9f3c4770d03d for future reference)
<steev>
check the date on them?
<kuruczgy[m]>
Got the green line with the one mentioned above, so at least that hash is now known working. (Also confirms that my Nix built version of slbounce is working, it's like 2KB smaller than the prebuilt version so I was afraid that something would be wrong, but I guess it's just different optimization flags that fortunately don't break anything.)
<kuruczgy[m]>
The one in /Windows/System32 is actually the oldest one, from sep 14. The other ones are from oct 4 and nov 9. The sizes are also wildly different, ranging from 872 KiB to 30 KiB. Lemme try the other ones
<kuruczgy[m]>
Nope, none of the others work, they all fail with "PE format is invalid."
todi has quit []
todi has joined #aarch64-laptops
<steev>
interesting
davidinux is now known as Guest1052
davidinux has joined #aarch64-laptops
davidinux is now known as Guest1053
Guest1052 has quit [Ping timeout: 480 seconds]
chrisl has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
<travmurav[m]>
kuruczgy: i think there is some funny symlink stuff in windows but system32 one should be correct. This file is part of windows bootloader so signed by MS, seems to change often via windows updates and also seems to sometimes not authenticate if you use not the one from your install...
tobhe_ has joined #aarch64-laptops
tobhe has quit [Ping timeout: 480 seconds]
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
anozetsubou has quit [Remote host closed the connection]
anozetsubou has joined #aarch64-laptops
exeat has quit [Ping timeout: 480 seconds]
jhovold has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
alfredo1 has joined #aarch64-laptops
alfredo has quit [Read error: Connection reset by peer]
alfredo1 is now known as alfredo
alfredo1 has joined #aarch64-laptops
alfredo has quit [Read error: Connection reset by peer]
alfredo1 is now known as alfredo
bumble[m] has joined #aarch64-laptops
<bumble[m]>
<dunc4n> "also; what are the downs/ups..." <- x13s with postmarketos is my favorite linux machine of all time. silent and passively cooled, super lightweight, great keyboard, battery lasts long time (after watching the movie "den of thieves" un-plugged, machine still had over 80% battery)
<bumble[m]>
to be fair these are the problems I encounter occasionally: _sometimes_ the screen stays black after opening from a sleep state and holding the power button to shutdown is needed. wifi seems weak or flakey sometimes
<bumble[m]>
still the best
SpieringsAE has joined #aarch64-laptops
<jhovold>
bumble[m]: are you using an external display? the dp state machine in the drm driver is known to be broken and can cause such resume issues
<jhovold>
(e.g. if disconnecting or powering off the external display after suspending)
<bumble[m]>
@jhovold (thank you for making x13s so good)
alfredo has quit [Quit: alfredo]
alfredo has joined #aarch64-laptops
martiert has quit [Quit: WeeChat 4.4.3]
<bumble[m]>
wondering if the recent x13s bios update mentioned earlier resolves anything
alfredo1 has joined #aarch64-laptops
martiert has joined #aarch64-laptops
sally has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
alfredo1 is now known as alfredo
iivanov has joined #aarch64-laptops
<SpieringsAE>
has anyone with a t14s already opened it up and taken a good look at the hdmi situation? I am still trying to make some sense out of it on my asus, it seems to me that mdss_dp2 would go to this thing, but it seems to me like the DP stream is already getting merged into the usb4 stream inside the SOC
<SpieringsAE>
and is not just a separate DP bus coming out, but somehow this needs to go to this ps185hdm-a1 chip which will convert it to hdmi, there is still that 3rd ps8830 that is listed in the dsdt, but which I could not find on the pcb, perhaps it is indeed on the backside?
<SpieringsAE>
anyways I think the t14s has a very similar layout so yeah, I wonder how the situation is on that one
alfredo has quit [Ping timeout: 480 seconds]
<kuruczgy[m]>
Does anyone know if there is some sane way to use slbounce with systemd-boot? Or am I pretty much forced to use GRUB?
<travmurav[m]>
Depends on the definition of "sane"
<travmurav[m]>
I have a semi hacked branch to enable sl if the dt overlay is loaded
<travmurav[m]>
So you put slbounce into driver dir to load unconditionally and have two boot options with normal dtb and dtb+overlay
<kuruczgy[m]>
Oh does systemd-boot just automatically load drivers from a specific dir? Or does EFI do that automatically? Either way, that sounds like what I am looking for.
<travmurav[m]>
Sdboot, yes
<travmurav[m]>
It's in the readme
<travmurav[m]>
Ah it's in dtbloader readme
<kuruczgy[m]>
Found it, thanks. Will also check the systemd-boot source later. Could you point me to that branch of yours? Because if I want to be able to choose EL1 or EL2 boot from systemd-boot that detection also seems necessary.
<kuruczgy[m]>
Another thing I was wondering about: what's preventing the adsp from working in EL2? How difficult would it be to get it working?
<Jasper[m]>
iirc (I'm not too well versed with the details) the current driver for these remoteprocs does not account for the fact that you are in el2
<Jasper[m]>
HYP (which you are basically bypassing) does some stuff with the place in nemory you're supposed to load those mbn files from that are not performed in el2
<Jasper[m]>
There's probably more weird stuff to account for when in el2, but iirc that was the big one
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
exeat has joined #aarch64-laptops
nothorseface has quit []
nothorseface has joined #aarch64-laptops
SpieringsAE has quit [Remote host closed the connection]
SpieringsAE has joined #aarch64-laptops
<travmurav[m]>
kuruczgy: nothing prevents it, just that the hyp is the thing that boots it
<kuruczgy[m]>
travmurav: And how complicated is that "booting" procedure? Should we expext linux to learn it any time soon? Or alternately, could we somehow ask the hyp to boot the adsp _before_ we slbounce?
<travmurav[m]>
kuruczgy: there is a driver in linux that is almost/fully correct to boot the adsp but the problem is knowing what resources to kick (i.e. what clocks, what pds) which is specific to the soc
<travmurav[m]>
and as you know qcom doesn't share any documentation with independants
<travmurav[m]>
I think the problem trying to boot the dsp and then killing hyp is that you'd need to somehow preserve iommu settings properly
<travmurav[m]>
I doubt it would survive
<macc24>
travmurav: couldn't the el2 firmware be reversed to find out what needs to happen?
<travmurav[m]>
it could
<travmurav[m]>
on 7c I got to boot fsm reporting success but the adsp never fetched instructions from ram
<travmurav[m]>
and on my thing iommu faults seem to be trapped by tz or something so can't properly check what's going on anwyay
<travmurav[m]>
there was one clock I didn't kick that was kicked by hyp but I never end up testing if that wouldve helped
<travmurav[m]>
and for 8c3/x1e you'd need to re that stuff again
<travmurav[m]>
find the clocks/pds, somehow know they /are/ clocks/pds...
<travmurav[m]>
since all you can see is just mmio accesses
<macc24>
:/
<travmurav[m]>
I guess unless you get leaked flats or what people use...
<travmurav[m]>
something I generally try to avoid
<kuruczgy[m]>
(Not sure what you mean by "leaked flats", but I guess I shouldn't ask...)
<travmurav[m]>
some people know where to find "proprietary and confidential" BSP bits for qcom platforms, which include firmware source code and some debugging stuff like (allegedly very extensive) memory maps
nothorseface has quit [Ping timeout: 480 seconds]
<travmurav[m]>
like, by staring at open source stuff like linux you can get somewhere but not everything was ""disclosed""
<travmurav[m]>
but it's just brainrot without register maps
<travmurav[m]>
(I got to "start timed out" I think in that driver)
<Jasper[m]>
Seems like my attempt at explaining it was one step too early hahaha
nothorseface has joined #aarch64-laptops
<travmurav[m]>
basically there is (theoretically) very little work needed to kick it
<travmurav[m]>
just that someone needs to suffer to find out exactly what resources are required and how to kick them on
<Jasper[m]>
Small step/requirement/amount of data, big work to get to that point.
<travmurav[m]>
and no one who /can/ help /will/ help
<Jasper[m]>
rip
iivanov has quit [Quit: Leaving...]
baozich has joined #aarch64-laptops
baozich has quit []
baozich has joined #aarch64-laptops
baozich has quit []
baozich has joined #aarch64-laptops
<JosDehaes[m]>
M4 max linux compile numbers: compiling wip/x1e80100-6.12 of johan's tree with johan_defconfig (in docker container as there's no asahi for M4 yet): make -j16 takes 1m1s
<JosDehaes[m]>
I don't have the yoga with me today, but I'd say that's a lot faster than on the yoga 7x 😁
nothorseface has quit []
nothorseface has joined #aarch64-laptops
<robclark>
JosDehaes[m]: 1m43 on x1e-78 .. so faster, but not _way_ faster, esp considering the core count difference and _especially_ the price difference
* travmurav[m]
kinda wants to know how many coulombs each of those two took to compile it
<robclark>
(and I guess if price is no object, ampere has you covered.. I guess 192 cores can compile a kernel pretty quick)
<robclark>
JosDehaes[m]: I'd be interested to see what the compile time is on the m4 w/ 4k pages (but I guess you would need to do that in a linux vm?) ... android folks are claiming something like a 10% uplift from using larger pages, so I guess that is at least some of m4's advantage
<hogliux>
kuruczgy[m]: I then have two grub settings, one for normal boot in EL1 and one for EL2 which calls `efidriver` with slbounce before loading the kernel
<hogliux>
kuruczgy[m]: this has the benefit that you can just have two dtbs - one for the EL1 kernel and one for the EL2 kernel
nothorseface has quit []
nothorseface has joined #aarch64-laptops
SpieringsAE has quit [Quit: Leaving]
<JensGlathe[m]>
hogliux sounds like the most straight forward way to do it. I guess I will convert my EL2 box to this when the day comes to redo it
<JensGlathe[m]>
Currently I have EDK2 EFI shell in the grub menu and load slbounce manually when I want to boot EL2. But I already have dedicated dtbs.
lak has joined #aarch64-laptops
<lak>
@tobhe do you want that T14s dmidecode on launchpad undecoded/dumped (dmidecode -t system -u)
chrisl has quit [Ping timeout: 480 seconds]
<tobhe_>
yeah, that would be great. Maybe redact your serial number since that seems to be per device
<tobhe_>
Version and SKU seem to be identical for OLED and non-OLED
<tobhe_>
not sure what the product name actually encodes after the 21N*
tobhe_ is now known as tobhe
<jannau>
JosDehaes[m], robclark: 1m53 on m1 max (8/2 cores), linux, with 16k pages. iirc 16k pages were closer to 15% than 10% faster for kernel compilation (measured with arm64 defconfig)
<kuruczgy[m]>
Oh even grub requires a patch? Then I will definitely try to get it working with systemd-boot first. But I will keep that patch in mind as a plan B, thanks.
<jannau>
the docker virt kernel on macos probably uses 4k pages though
<robclark>
yeah, wasn't clear to me if that was a container or vm.. (does macosx even have containers?)
<jannau>
I think both docker and podman on macos work by running containers in a virtualized linux
<robclark>
ahh
<lak>
@tobhe I've pasted it in, redacting the last 6 digits of the serial to zero. I don't think anything in this data decodes to the screen, and if you *do* use that people that upgrade the screen later will be in trouble
nothorseface has quit []
<JensGlathe[m]>
The only other work-around would be sensitivity in the edp-panel(?) and samsung OLED(?) drivers, but this is quite tedious. Better to have a selector at boot
<lak>
IDK anything about whats available at that point in time when the dtbs are loaded, is that EFI or has the kernel loaded yet?
<JensGlathe[m]>
it is before kernel loading
nothorseface has joined #aarch64-laptops
<JensGlathe[m]>
maybe dtbloader can help, but not sure
<tobhe>
dtbloader also only looks at dmi
<JensGlathe[m]>
but the BIOS signatures should be different, isn't there a GUID for it?
lak has quit [Quit: lak]
lak has joined #aarch64-laptops
<vickdu31[m]>
Good evening, do we have any X1 device with working speakers so far?
<JensGlathe[m]>
Yoga Slim7X and T14s AFAIK
<vickdu31[m]>
Ok, which repo should I look at for the latest DTS info? I am trying to make sense of it, to find something maybe workable for the Acer
<\[m]>
afaihs it's on the lkm, which is searchable online on lore whatever
lak has quit [Remote host closed the connection]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
nothorseface has quit []
<ppd[m]>
<JensGlathe[m]> "Yoga Slim7X and T14s AFAIK" <- Working is a interesting way to put it
<ppd[m]>
They don't have speaker protection.
<JensGlathe[m]>
"work"?
<ppd[m]>
7x is distorted
nothorseface has joined #aarch64-laptops
<ppd[m]>
I dunno about the T14 but I imagine it's "not much better"
<robclark>
sound seems ok for me on 7x.. but I also have the volume down fairly low (and my office neighbors probably prefer it that way)
<ppd[m]>
It's really not good, compared to windows.
nothorseface has quit []
nothorseface has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
<vickdu31[m]>
Actually on my windows it is really bad compared to other laptops (on acer), now after Bios update the DTS app finally works (for DTS X support) but it is still of of the worst laptop I have had... I'm on the Acer
<vickdu31[m]>
* Actually on my windows it is really bad compared to other laptops (on acer), now after Bios update the DTS app finally works (for DTS X support) but it is still of of the worst laptop I have had...
chrisl has quit [Ping timeout: 480 seconds]
hogliux has quit [Quit: Page closed]
Guest1053 has quit [Ping timeout: 480 seconds]
<macc24>
are there any disadvantages to just shipping the entire kernel tree for updates besides file size? as in build kernel, shove into a .tar.gz and put that out as an updatr
weirdtreething has quit [Ping timeout: 480 seconds]
<steev>
why do that instead of just installing into a temp directory and tar that up?
<steev>
if you're just providing the built stuff
<steev>
the main downside would be end users having to move things in place (and if they have different toolchain, it might have to rebuild)
davidinux 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]
hCal has joined #aarch64-laptops
weirdtreething has joined #aarch64-laptops
<hCal>
Hi all. I saw that some x13s linux developers/folks hung out here. I'm thought Id drop by and say thanks - my x13s rocks right now. I hope the new Snapdragon systems are coming along just as well.
jhovold has quit [Ping timeout: 480 seconds]
<ppd[m]>
...something like that
<logan2611>
Why is it that kexec using the new file method doesn't use the DTB that I specify
<logan2611>
Seems like the issue was fixed 6 years ago but I've never had it work
<hCal>
I was looking through the channel logs and it looks like some people are trying 6.12. I'm on 6.11.0-0-x13s from the ironrobin isos installation. Is it safe to go mainline yet?
<hCal>
on the x13s, btw
<JensGlathe[m]>
not much that isn't mainline for x13s
<JensGlathe[m]>
only Venus Codec, and WCN6855 BT firmware filename generation, AFAICT
djakov has quit [Remote host closed the connection]
<steev>
pretty much yeah
<steev>
various minor (and sometimes major) bugfixes but those will make it into stable at some point too