ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
alpernebbi has quit [Ping timeout: 480 seconds]
alpernebbi has joined #aarch64-laptops
<harvestz[m]> nice, linux is faster?
<selmer443[m]> That multi core improvement though… nice
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<steev> yeah, it has been for a while
<harvestz[m]> I've only done dev on windows twice but in previous places I've worked windows is pretty much always slower when bench marked on the software in house
<steev> well, before bamse's patches, we benchmarked a bit lower
<steev> and once we get the gpu up, we'll probably be sitting pretty
<steev> which, currently, i'm at https://paste.debian.net/1265405/ and stuck because i have no idea what dependency it's claiming its waiting on, and nothing is actually in the deferred_devices
<harvestz[m]> can't wait for the gpu support :p
<steev> oh
<steev> i think i figured out the missing dep, but lets see
<steev> ahhhh right, now i know where we are at
<steev> we still have that unbalanced pm runtime
<steev> it was timing out because i hadn't enabled GPUCC_8280XP :D
<HdkR> steev: But what does it do with gpucc enabled? :P
<steev> the second paste
<steev> maybe we are missing some interconnect or something
<HdkR> Ah, I missed the first one
jhovold has joined #aarch64-laptops
SSJ_GZ has joined #aarch64-laptops
<jhovold> steev and anyone else using a linux-nexyt
<jhovold> steev and anyone else using a linux-next: here's an updated branch based on 6.2-rc1 which has a fix for an nvme regression that was reported over the weekend:
<jhovold> it also has a fix for some UFS deadlocks on Qualcomm platforms, which ajhalaney[m] and anyone using UFS storage may want
<ajhalaney[m]> Oooo nice thanks jhovold
<ajhalaney[m]> dgilmore I'm traveling otherwise I'd be more help, but for some reason fedora grub died hard when we tried it many moons ago. Debians worked. Everyone I know of running fedora with the x13s just switched to systemd-boot for now
<bamse> steev: i'm told that geekbench in wsl beats windows as well, so question is what differs in terms of compiler optimizations etc between the two binaries
<bamse> steev: but really nice to see still :)
<bamse> jhovold: nice!
<Caterpillar> I would like to thank everyone working on X13s support. I am looking forward to test new kernels to benefit of power usage optimization
<selmer443[m]> ^ditto
<dgilmore> ajhalaney[m]
<dgilmore> gahh
<dgilmore> ajhalaney[m]: thanks. though looks like it does not support devicetree at all
<ajhalaney[m]> If you use dtb= and the kernel EFI shim you should be off to the races dgilmore
<ajhalaney[m]> Or dtbloader
<dgilmore> dtbloader is currently not buildable
<bamse> dgilmore: is that because the code doesn't compile with modern tools? or something else?
<dgilmore> It does not compile with modern compilers
<ajhalaney[m]> Someone gave me a binary a while back, I've never tried to build it. I recommend just using dtb= on the kernel/shim command line personally just cuz it's a little more flexible imo. I borked my setup too many times with just one dtb to replace with dtbloader
<bamse> ajhalaney[m]: when i tried dtb= the efi code in the kernel concluded that i had secure boot enabled and kindly ignored the option...but it works as expected now?
<bamse> ajhalaney[m]: might have been too early for things to behave sanely
<dgilmore> systemd-boot seems completely broken in design for precanned images
<ajhalaney[m]> bamse: there's a possibility that I have been accidentally still using the dtb provided by dtbloader for a long time, and at the moment don't have my x13s to validate, but I do have a slow mo video from last week where I was debugging something and I see "EFI stub: Using DTB from command line" so I believe I've been using the new dtb from dtb= and not riding on dtbloader
<bamse> ajhalaney[m]: a terrible source of confusion ;)
<ajhalaney[m]> I like systemd-boot but I don't have the knowledge to enter any holy war about it dgilmore :) -- iirc you at least piped up over the fedora UKI proposal
<dgilmore> ajhalaney[m]: that it is tied to the machine-id and a precanned system shoould not have one until first boot so they are all unique is a chicken/egg problem that somehow needs sorted. and maybe the one generated at install time and having it changed on first boot is not a big deal
<dgilmore> ajhalaney[m]: I just raised concerns that caused us to not build an initrd at kernel compile time in the past
<dgilmore> I do not have a strong opinion either way
<ajhalaney[m]> Yeah I suppose I'm making the mistake of relating systemd-boot and UKI in general which is a reoccurring theme on that thread
<dgilmore> as long as I can boot my system I am okay
<dgilmore> the random-seed in /loader is also problematic on a premade disk image
<dgilmore> having all systems using the same values is a bad idea
<bamse> someone expecting the os-loader to pick up and adjust that value?
<dgilmore> well systemd-boot is a flop, it tells me that the linux binary is unsupported
<dgilmore> That is a mirrored VM
<dgilmore> but much the same
<Dylanger> I just pulled in https://gitlab.collabora.com/google/chromeos-kernel/-/commit/3a498f84ddf3f8090e138cd9c443a62b767479ea but I still can't seem to get the VP9 or AV1 hw video decoder to work for the MT8195
<dgilmore> decompessing the kernel helps
<steev> jhovold: thanks! i'll look at it when i have some time.
<dgilmore> ajhalaney[m]: thanks for the tip. the initrd in the image I built is broken, missing some modules, but I got further, I will have to file a bug with grub. need to manually decompress the kernel.
<dgilmore> going to try f37
<dgilmore> seems USB and the keyboard are not working
<steev> on the c630?
SSJ_GZ has quit [Ping timeout: 480 seconds]
<steev> robclark: the blah_gmu.bin file is just to kick us out of secure mode? or is only the sqe that does that?
kettenis_ has joined #aarch64-laptops
kettenis has quit [Ping timeout: 480 seconds]