robclark 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
<Dantheman825[m]>
I’ve been wanting to try jhovold’s kernel branch, but I’ve been having trouble getting it to boot. I’ve compiled a couple of times, one time with the johan config, and another time with the laptop defconfig ported over. But no matter what, it gets stuck loading the dtb
<Dantheman825[m]>
I install my kernels via make, and the dtbs get installed in `/boot/dtbs/<kernel>`, and I made sure in the grub config to have it point to the correct dtb for the kernel
<bamse>
Dantheman825[m]: do you pass "arm64.nopauth efi=noruntime efi=novamap clk_ignore_unused pd_ignore_unused" on your kernel command line?
<bamse>
hmm, think efi=novamap is deprecated, but lacking either one of hte two first will cause a hang at about that point in the boot
<bamse>
Dantheman825[m]: i.e not "arm64.nopauth efi=noruntime ?
<bamse>
without the "
<bamse>
Dantheman825[m]: do you have the "experimental linux support" checked in your bios?
<HdkR>
bamse: Is pauth problems fixed to not need that flag anymore?
<bamse>
HdkR: qualcomm fixed it, but lenovo doesn't have the fix...i've tried to figure out how that's possible
<HdkR>
:|
<bamse>
i should try again...and harder...
sjs_ has quit [Ping timeout: 480 seconds]
<Dantheman825[m]>
<bamse> "Dantheman825: i.e not "arm64...." <- This was my issue, adding these fixed it
<Dantheman825[m]>
Thank you
<Segfault[m]>
i've come up with a slightly better thermal throttling setup for the x13s although the way linux changes the thermal throttling state isn't as smooth as i'd like, for some reason instead of basing the throttle amount on the hysteresis range it just increases the throttling from minimum to maximum over the period of about a second https://termbin.com/6bpi
sjs_ has joined #aarch64-laptops
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<bamse>
Segfault[m]: if i understood jhovold correctly it does so because we don't provide all the energy properties...
<bamse>
Dantheman825[m]: nice!
<travmurav[m]>
bamse: any chance you know which resources (clocks pds?) need to be on for pcie smmu on sc8280xp? Or nda go brrrr?
hightower3 has joined #aarch64-laptops
<travmurav[m]>
we can configure the smmuv3 to allow dma from pcie and seem to at least read nvme partition table, but then linux hits some cleanup(?) code after a bit of time and the device dies immediately
<travmurav[m]>
I'm guessing we're just lucky the resources are on while we use pcie but then things get disabled and touching iommu results in some serror (trapped by tz I guess)
hightower4 has quit [Ping timeout: 480 seconds]
svarbanov has quit [Ping timeout: 480 seconds]
jglathe_volterra has joined #aarch64-laptops
jglathe_volterra has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
<steev>
travmurav[m]: while using clk_ignore_unused?
<travmurav[m]>
I suspect the clocks are actually used since we can use the iommu for some time (to allow pcie to do dma) but the device still unconditionally dies after a while
<travmurav[m]>
but yes, clk/pd ignore unused as I guess is still needed on sc8280xp anyway(?)
jglathe_volterra has joined #aarch64-laptops
<steev>
not using them here, surprisingly enough
<steev>
just using the debian 6.6.3 kernel, not even the heavily patched stuff :)
<steev>
though 6.7.4 should be in experimental soon
<steev>
or i thought it would be, the git repo said prepare for release :(
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
svarbanov has joined #aarch64-laptops
sjs_ has quit [Ping timeout: 480 seconds]
sjs_ has joined #aarch64-laptops
<jhovold>
_[m]123, jglathe_volterra: both the internal and external displays share some display-port related drivers and code
<jhovold>
and there are some regressions in 6.8-rc that affects both
<jhovold>
just not sure yet whether the reset that bamse is seeing is related to that or something else
sjs_ has quit [Ping timeout: 480 seconds]
<jhovold>
Dantheman825[m], bamse: arm64.nopauth is indeed the one that is needed to be able to boot, efi=noruntime is needed to prevent a crash on reboot/shutdown
<jhovold>
and the latter is not needed when "Linux Mode" is enabled in the UEFI setup, but doesn't hurt keeping it there
<jhovold>
Segfault[m]: the thermal throttling is indeed not optimal, and leads to the CPU frequency oscillating too much instead of finding a steady state
<jhovold>
I could squeeze out some more performance by playing with the parameters (like polling rate), but what really need is a proper thermal model of the CPUs
<jhovold>
it's on that evergrowing todo list, regression and bugs go at the top, performance towards the bottom...
sjs_ has joined #aarch64-laptops
<ema>
steev, _[m]123: kernel 6.7.4-1~exp1 is now available in experimental - apt install linux-image-6.7-arm64-unsigned
<ema>
that includes both QCOM_SPMI_ADC_TM5 (thermal support) and the seecom settings for efivars
<steev>
\o/
anarchron has joined #aarch64-laptops
martin has joined #aarch64-laptops
<_[m]123>
hot 🙂
<steev>
or not :D
martin is now known as Guest2170
hightower4 has joined #aarch64-laptops
hightower3 has quit [Ping timeout: 480 seconds]
hightower4 has quit [Ping timeout: 480 seconds]
sjs_ has quit [Ping timeout: 480 seconds]
jglathe_sdbox2 has quit [Remote host closed the connection]
<_[m]123>
installing
<_[m]123>
so on resume today, surprise not internal screen and external was doing it's no device connected thing haha
<_[m]123>
interesting jhovold, so I probably want to run older version right
<_[m]123>
let's boot this baby up !
<_[m]123>
it's pretty ironic steev not running their own patched kernel 😄
<_[m]123>
vpn connecting, something is fckng the dns though
<jhovold>
_[m]123: yeah, if you hit the 6.8-rc display regressions too often you may want to stick to 6.7 for a while still
<jhovold>
i've only seen the internal display not come up twice, and no hard resets except when I tested the external display
<jhovold>
so 6.8-rc3 is stable enough for me at least
hightower2 has joined #aarch64-laptops
sjs_ has joined #aarch64-laptops
Libre___ has quit [Ping timeout: 480 seconds]
<_[m]123>
maybe it's specific to this tv - I use samsung tv as external screen in the couch
sjs__ has joined #aarch64-laptops
sjs_ has quit [Ping timeout: 480 seconds]
<Dylanger>
I'd like to package Fedora's aarch64 Kernel to boot on an aarch64 Chromebook running Depthcharge as it's bootloader but the 32MB size limit of the kernel partition won't be enough for the kernel + initramfs/dracut, does anyone know what the actual limitation of 32MB is?
<Dylanger>
I have a SuzyQ + the ability to compile my own Depthcharge Bootloader
<Dylanger>
Ultimately Fedora should provide kernels ready for Depthcharge/aarch64 Chromebooks
<Dylanger>
But it might be the kernel size that's stopping them from doing that
<Dylanger>
TL;DR I'm sick of having to compile mainline myself every few months and just wanna use Fedora's kernel
<Dylanger>
That should also fix SELinux
<maz>
Dylanger: the correct way to address this is to have a proper bootloader for Chromebooks. Something that would allow EFI images from being booted.
<Jasper[m]>
i.e. edk2 or u-boot
<maz>
that.
<Jasper[m]>
Problem is that Google's downstream coreboot patches rarely land fully functional upstrean
<maz>
asking distros to provide device-specific kernels is not going to fly.
<maz>
oh, it would be an uphill battle. I've tried that back in the A15 days, and lost the will to live over it.
<Jasper[m]>
Jasper[m]: Same for cros-ec btw, they just get thrown away when the device loses support
<Dylanger>
maz: I agree, but that's too much work for one lilguy
<Jasper[m]>
I've been running into issues with that last one specifically, my pixel c runs unfinished firmware and it lost support for the linux platform driver somewhere inbetween 4.14 and 5.9
<Dylanger>
My Acer MT8195 is totally mainline'd now so it should boot Fedora's Kernel perfectly
<Jasper[m]>
Well yeah, but Fedora only supports EFI targets
<Dylanger>
Are there any community efforts to get U-Boot working on aarch64 Chromebooks?
<Dylanger>
Jasper[m]: Yeah I had to do all sort of stuff to extract rootfs from the image and load it onto my f2fs Chromebook 🤦♂️
<Jasper[m]>
Dylanger: Libreboot has _some_ work done on it
<Dylanger>
Literally everything works except SELinux and Sound (sof isn't working yet)
<Jasper[m]>
But like I said, your best bet is to check support in upstream coreboot
<Dylanger>
🤔 there's already some mentions of Coreboot in the bootloader log
<jenneron[m]>
in postmarketOS we include only required stuff into initramfs, this way we have it working even on devices with 8M limit
<Jasper[m]>
Dylanger: Yes, downstream, google patched
<Jasper[m]>
All chromebooks use coreboot
<jenneron[m]>
they upstream stuff
<jenneron[m]>
maybe not everything but still
<Jasper[m]>
jenneron[m]: Hence my suggestion to check ;)
<Dylanger>
jenneron[m]: I like to use LUKS'd rootfs, dracut is such a big boi
<jenneron[m]>
Dylanger: yeah we support that on devices with 8M limit as well :P
<Jasper[m]>
But if that works somewhat you may just use edk2 or u-boot as a payload
<jenneron[m]>
our solution for FDE is to have a secondary ramdisk on ext2 partition, this way chrome os kernel image does not increase, but we still have utilities for unlocking rootfs there
<jenneron[m]>
but i doubt you can do something like this on fedora easily
<jenneron[m]>
> Since the writing of this things have changed. Our goal is still to have privilege separation, but this is no longer the path we likely will take.
<jenneron[m]>
speaking of your 32M partition on internal storage, I would just nuke partition table and create a new one
<Jasper[m]>
<HdkR> "Jasper: I have a couple of spare..." <- I have a feeling you're not anywhere near close to the Netherlands :p
<Dylanger>
Jasper[m]: I have some HDKs you can have
<Dylanger>
jenneron[m]: Cheers, I'll give it a go
<HdkR>
Jasper[m]: Silicon Valley is a bit far
<Jasper[m]>
HdkR: Haha yes
<Jasper[m]>
Dylanger: Which ones are you interested in selling?
<jenneron[m]>
Dylanger: i mean the partition table, not just kernel partition
<Dylanger>
Jasper[m]: I'd just give to you, the Snapdragon 888 HDK I was talking about earlier
<Jasper[m]>
Dylanger: Oh
<Jasper[m]>
That would be cook
<Jasper[m]>
l
<Jasper[m]>
Why are you getting rid of it?
<Dylanger>
I wanted to use it as a NAS, but m.2 is keyed for SATA not NVMe
<Dylanger>
jenneron[m]: Yeah may as well, I'd have to re-partition rootfs as well
<Jasper[m]>
Ah, well I'll gladly give it a home. Wanna continue in dm's?
<Dylanger>
Yeah sure
<_[m]123>
same issue on this kernel with the external monitor not getting signal BUT it's recognised and on and my windows are there
<Segfault[m]>
<jhovold> "it's on that evergrowing todo..." <- fair enough, the only reason i was even looking at it was because only throttling the big cores sometimes isn't enough to completely cap the temperature in my experience
<jenneron[m]>
Dylanger: huh, do you several of them? i'm looking for something that has more than 8 GB RAM for home server purposes, maybe you have something to sell
<Dylanger>
jenneron[m]: I don't have anymore but if I come across more I'll dm you 👍
<_[m]123>
changing usb c port usually triggers
<_[m]123>
whoa I need to get a blanket now the laptop is not heating me 😲
hightower2 has quit [Ping timeout: 480 seconds]
Libre___ has joined #aarch64-laptops
todi has joined #aarch64-laptops
ak-coram has joined #aarch64-laptops
<ak-coram>
what's up with the webcam support for the x13s? I recall seeing some people getting it working some time ago: is there any documentation around on what's needed to get it up and running?
svarbanov has quit [Read error: Connection reset by peer]
<_[m]123>
I think it was using some specific Mozilla library,can't recall fully
svarbanov has joined #aarch64-laptops
hightower2 has joined #aarch64-laptops
<bamse>
travmurav[m]: so smmuv3 works a little bit, but then dies, or not at all?
<travmurav[m]>
bamse: smmu works properly, we can assign stream ids, map memory through it. It correctly shows transtation faults for bad dma...
<travmurav[m]>
but
<travmurav[m]>
any time we enable it in linux, after a while the device reboots, no serror or panic
<travmurav[m]>
tied specifically to enabling that smmu
<travmurav[m]>
(regardless if pcie was assigned to it or not)
<travmurav[m]>
so my guess was that it works because pcie holds some common clocks, but then pcie gets suspended, clocks turned off and linux tries to touch that smmu after, or something like that...
<bamse>
works in pre-linux testing? or works during boot of linux?
<travmurav[m]>
works during boot, we can see smmu events in log on the screen until device reboots
<travmurav[m]>
(or see nvme enumerate partitions properly to confirm dma works for example, it doesn't without iommu)
<bamse>
okay, so smmu driver probes, nvme driver probes and then it magically breaks?