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)
<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>
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
<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
<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?