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
<travmurav[m]>
I think I will just do some heuristic like checking status=disabled in the zap shader
<travmurav[m]>
which so far is only the case for el2 overlays
<kuruczgy[m]>
Yeah that sounds quite hacky... also I could see in the future being able to easily tell if a device tree was meant to be booted in EL2 being useful for other things as well (e.g. debugging or some sanity checks)
<travmurav[m]>
well it's quite clear from the presence of iommu/lack of zap shader since both will crash/hang el1
<travmurav[m]>
and zap shader is universal so far
<travmurav[m]>
(I've also stripped the compatible metadata headers since we don't have them for other overlays in qcom and since -el2.dtb are pregenerated for most usecases then anyway)
<travmurav[m]>
sadly more generally neither el1/el2 dtb nor presence of overlays really help fully generic images I think (unless we can fix adsp and just use el2 always) so there will always be some jank
ema has quit [Quit: leaving]
ema has joined #aarch64-laptops
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
svarbanov__ has quit [Ping timeout: 480 seconds]
exeat has quit [Remote host closed the connection]
exeat has joined #aarch64-laptops
jdb has joined #aarch64-laptops
<macc24>
travmurav: what if slbounce loads adsp firmware? before switching to el2?
JrmedeBretagne[m] has joined #aarch64-laptops
JrmedeBretagne[m] is now known as JeromedeBretagne[m]
chrisl has joined #aarch64-laptops
srinik has quit [Ping timeout: 480 seconds]
<travmurav[m]>
It probably could
chrisl has quit [Ping timeout: 480 seconds]
<travmurav[m]>
There are few funny implications but given linux currently just sets all sids previously enabled in iommu to pass through it'd keep the adsp going i guess, at least the same applies to adsp-lite which afaiu works in el2
<Jasper[m]>
Bit of an ignorant question from me too, is there anything to withold you from performing slbounce's trick from Linux booted in el1?
<Jasper[m]>
Or is QHEE/Gunyah initialized up to a point where you can't after ebs?
<travmurav[m]>
You need to do it after ebs
<travmurav[m]>
Bur also need to only have one core running for example, and the cpu state will be cleaned, probably with more side effects
<Jasper[m]>
I'm trying to figure out what window you have of doing it, if doing it from EFI is the only option or not.
<Jasper[m]>
Would be funny if you could create a kernel image that sets itself up the way you want, boot adsp like mac suggested and then jump to el2. Basically lk2nd all over again
<Jasper[m]>
(The reason why I called it an ignorant question, is because I have no detailed clue about how bootstrapping these platforms works)
<Jasper[m]>
Or make a dxe that does the big adsp loading, that's probably the nicer choice
<travmurav[m]>
I'd feel it's probably simpler to just write whatever code is needed to boot the remoteproc from a cold core tbh
<travmurav[m]>
than to figure out how to basically kexec linux from linux that suffered a complete cpu reset
<Jasper[m]>
Yes, my linux kernel image suggestion was mostly from a place of "we know this driver works up to some point"
<travmurav[m]>
I mean I already did similar stuff for 7c1
<travmurav[m]>
where I needed to do some hyp-provided smc to assign rmtfs memory to the modem so it can boot
<travmurav[m]>
it can be done
<travmurav[m]>
I guess the annoying part is that it's likely adsp needs to be replaced after ebs too, in case uefi wants to do stuff with adsp-lite on ebs for example
<travmurav[m]>
uefi doesn't tocuh adsp-lite on ebs I guess
<travmurav[m]>
well
<travmurav[m]>
one way to find out
<travmurav[m]>
but what I'm worried about is whether uefi has some running threads that talk to it which would break if we replace it while in boot services
<travmurav[m]>
so it'd be safest to reboot adsp after ebs but before booting linux I think
srinik has quit [Ping timeout: 480 seconds]
<travmurav[m]>
of course the nicest would be to figure out how to boot it from linux but oh well
pbrobinson_ has quit [Remote host closed the connection]
<anonymix007[m]>
It seems to be just a couple of SMC calls
jdb has quit [Quit: jdb]
jdb has joined #aarch64-laptops
jdb has quit []
jdb has joined #aarch64-laptops
jdb has quit []
chrisl has joined #aarch64-laptops
pbrobinson has joined #aarch64-laptops
<anonymix007[m]>
One thing I don't understand is how running Linux in EL2 breaks these SMC calls. Shouldn't they directly jump to EL3 (aka TZ/QSEE)?
<travmurav[m]>
if you mean whatever linux uses in el1 to boo the adsp, it's implemented in hyp
<travmurav[m]>
it traps smc
<travmurav[m]>
it also traps psci and other stuff
<travmurav[m]>
and some stuff it passes through and many things just implements/proxies to other calls
<travmurav[m]>
so qhee/gunyah literally turns clocks/power-domains on for adsp afaiu
<travmurav[m]>
and takes it out of reset
<travmurav[m]>
sets up iommu etc etc
<travmurav[m]>
funnily on mobile platforms the modem is actually booted by tz, but not other dsps
<travmurav[m]>
modem is special
<travmurav[m]>
but compute platforms don't have that
jdb has joined #aarch64-laptops
jdb has quit []
jdb has joined #aarch64-laptops
jdb has quit []
chrisl has quit [Ping timeout: 480 seconds]
<travmurav[m]>
and even for modem I had to call into hyp so it calls to tz in a different way to set up xpus for the modem
jdb has joined #aarch64-laptops
jdb has quit []
<JeromedeBretagne[m]>
Back with a working external screen on the Surface Pro 9 5G, running a 6.10 build and the DTS I had submitted upstream! Now I will try to keep this setup working on more recent kernel versions
<JeromedeBretagne[m]>
During my investigation today, I was wondering : what's the qcslpi8280.mbn firmware used for ?
<JeromedeBretagne[m]>
Should it be in the initramfs image or not?
<travmurav[m]>
slpi is sensor hub core iirc
<JeromedeBretagne[m]>
Thanks. Do you know if it is device specific? Or is it shared for a given platform like the sc8280xp?
<travmurav[m]>
I don't remember if the configs are separate sadly
<travmurav[m]>
but I think I vaguely recall it being not generic on phones
<anonymix007[m]>
travmurav: there seems to be a EFI PIL protocol. Maybe firmware could be loaded before ebs
<travmurav[m]>
and I think there was some work for in-kernel one that would plumb it into iio
<JeromedeBretagne[m]>
Thanks travmurav: so not used to boot anything critical / mandatory. I'll have to check on my Windows partition if I can find this file and see if it is identical to the Lenovo X13s one
<travmurav[m]>
I don't remember anyone caring about slpi on x13s so I'd not be surprised it's just because it's a tablet
chrisl has quit [Ping timeout: 480 seconds]
<travmurav[m]>
that they use ssc
<travmurav[m]>
for some accelerometer etc
tobhe has joined #aarch64-laptops
<JeromedeBretagne[m]>
it's part of the firmware-qcom-soc package, so officially distributed
tobhe_ has quit [Ping timeout: 480 seconds]
<travmurav[m]>
doesn't seem like slpi is defined at all for sc8280xp
jdb has joined #aarch64-laptops
jdb has quit []
jdb has joined #aarch64-laptops
jdb has quit []
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<JeromedeBretagne[m]>
Jens Glathe: (good) surprise, today I've been able to boot with your 6.15.0-rc4-jg-1 and the upstream dtb, by switching to a different external monitor!
<JeromedeBretagne[m]>
It works with my own build from jhovold 6.15-rc4 too, with the same HDMI screen. It seems one of my external screens is picky (it only has a USB-C Display Port input)
<JensGlathe[m]>
My build should give you some dmesg on usb-sbu-mux
<JeromedeBretagne[m]>
I will have a look, but not easy when I get an automatic reboot
hogliux has joined #aarch64-laptops
hogliux has quit [Remote host closed the connection]
<JeromedeBretagne[m]>
I will also need to add the surface-related modules in the jhovold config, otherwise I don't have the surface keyboard and touchpad working
hogliux has joined #aarch64-laptops
<hogliux>
@tobhe: I have my own kernel image based on jhovold's kernel with a bunch of extra patches for slim 7x and some other patches specific to my work. I like to create a ppa and ubuntu package for that kernel. Apart from kernel config, are there any Ubuntu specific patches that get applied to upstream linux kernels?
<hogliux>
I've used Ubuntu concepts and your work as a starting point before, but the git history is a bit confusing to me, so I don't know exactly which kernel the ubuntu concepts kernel is based on and if any ubuntu specific patches are applied.
hogliux has quit [Quit: Leaving]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
<steev>
hogliux: check the debian/patches directory in the ubuntu concept kernel sources (or the debian/patches/series file)
juergh_ has joined #aarch64-laptops
juergh has quit [Read error: Connection reset by peer]
chrisl has joined #aarch64-laptops
<tobhe>
steev: that usually works for packages but not for the kernel since that has all the patches applied directly
<robclark>
it means some driver hasn't loaded yet... I guess icc in this case
<robclark>
usually that is ok.. the kernel keeps a list of probe-deferred drivers, and tries them again once some driver has probed successfully
erebion has quit [Remote host closed the connection]
erebion has joined #aarch64-laptops
<dgilmore>
I threw Fedora 42 on the MS DevKit, while it boots fine, gdm refuses to start. I am suspecting it does not like using wayland . anyone had any success?
<robclark>
dgilmore: I have f42 (albeit with my own kernel) on my slim 7x.. using g-s wayland session with no issue
<robclark>
journalctl have anything interesting?
<erebion>
robclark: Is this something I should look into?
<erebion>
qcom_pmic_glink pmic-glink: Failed to create device link (0x180) with a600000.usb
<erebion>
qcom_pmic_glink pmic-glink: Failed to create device link (0x180) with a800000.usb
<erebion>
qcom_pmic_glink pmic-glink: Failed to create device link (0x180) with 88eb000.phy
<erebion>
qcom_pmic_glink pmic-glink: Failed to create device link (0x180) with 8903000.phy