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
<robclark>
weird.. I just hacked mesa to hard code the override env var.. (but tbh mesa should be better at automatically falling back to zink if gallium driver fails and there is a non-sw vk driver)
<robclark>
but somehow I can't convince myself to look at the loader code on a Fri afternoon :-P
<HdkR>
lol pfft, wtf. I hardcode as well and it works
<robclark>
should be a short term problem but it would be nice if there was a more graceful fallback to zink... idk what nvk users are doing
<HdkR>
Rebuilding FEX rootfs so I can test there
<HdkR>
Looks like nvtop works out of the box as well, which is nice
<HdkR>
Just doesn't have a product name
<robclark>
would be nice if nvtop didn't have to duplicate chip-ids
<HdkR>
Don't think there would be a good way to get the product IDs otherwise. It doesn't understand GL/Vulkan, so would need something at the drm or kernel api level
<HdkR>
er, product names*
<anarsoul[m]>
<robclark> "should be a short term problem..." <- nvk users set `NOUVEAU_USE_ZINK=1` globally
<robclark>
hmm, that isn't much better than MESA_LOADER_DRIVER_OVERRIDE=zink
<HdkR>
But apparently works around the loader bug I guess :P
<robclark>
hmm, well that is conflating two things ... the native gallium _can_ probe but you'd prefer zink.. and the native gallium driver failing to probe
<robclark>
if native driver fails to probe then trying zink (if you have a non-sw vk driver) should be the default
<HdkR>
Yea, the Yoga I have returns 0xffff43050a01
dump_stack has quit [Quit: Page closed]
<gabertron>
Oh strange
<robclark>
so, until we have speedbin detection (if there are any) there should be no new chipid's.. the chipid comes from dts (but the speedbin comes from fuses/fw).. right now we are using 0xffff00000000 for speedbin which is the wildcard "match anything"
<robclark>
but the hack to override the chipid reported to userspace as a740 is causing confusion ;-)
<HdkR>
That's a weird chipid if it is masquerading as a740
<HdkR>
oh, it's the one without the speedbin
<HdkR>
I see
<HdkR>
Just had to check the other ones in the list :D
<HdkR>
oop, hangcheck. it might be a little unhappy
<HdkR>
wooo GPU faults with steam
<HdkR>
Looks like steam with Zink+Turnip is out of reach right now
<robclark>
I'll hopefully have non-zink option in the near future, but you should report/upload devcoredumps that don't involve zink (ie anything using vk natively)
<HdkR>
Bit hard to launch games when I can't start Steam :D
baryluk3 has joined #aarch64-laptops
<HdkR>
Looks like no external display support as well
<robclark>
yeah, not sure if anyone has looked at that yet.. I tried copying over crd dts but I guess it is wired up differently
<robclark>
so it is in need of someone who knows how to read acpi dumps
<sera[m]>
do you also get errors on sending messages over the glink edge from the battery manager and UCSI-or-DP alt mode enable? that seems to be what's blocking it from working for me
<sera[m]>
I can't find any documentation on how the glink unit works, might not be looking right but would be interested in trying to debug that if there was somewhere to start
<robclark>
umm, maybe? All I know is it didn't work
<robclark>
I can try experiments next week when I'm in the office (and have access to external displays)
<sera[m]>
On boot I get these two errors qcom_battmgr.pmic_glink_power_supply pmic_glink.power-supply.0: failed to request power notifications and ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: failed to send UCSI read request: -125. I re-enabled UCSI to test but before that the second message was about switching to DP alt mode, with the same error number
<sera[m]>
the cause is both trying to send a message over the rpmsg subsystem, which eventually fails in the glink SPI rpm driver
<sera[m]>
but I don't know where to start to debug further, yeah...
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<steev>
lumag might be working on that
<steev>
(but i'm not volunteering him to be, i just know he was digging around in there at some point)
<HdkR>
Nice
<HdkR>
Hopefully with T14s the HDMI output will work easily
<HdkR>
er, by the time I pick one up, since I do most of my development through HDMI capture :D
<travmurav[m]>
HdkR: do you happen to know what's the latency of your capture setup?
<travmurav[m]>
I guess it's a quite dumb question since it doesn't matter most of the time
<travmurav[m]>
I was trying to find a way to strap in a vr headset to the poor 7c1 which only has 2 dp lanes in hw, and what I realized I could do that I could capture the hmd feed at a lower res and use a capture pc as a "scaler" xD but capture latency + tracking latency (with tracking limited to 5Hz to actually do 5 camera SLAM on the poor 7c cpu as well as being able to run beatsaber) makes it so atrocious that it's not really that funny
<travmurav[m]>
anymore :(
<travmurav[m]>
I guess no vee arrr for me on 7c lol
<HdkR>
travmurav[m]: A frame or two of latency, but the audio is worse because I'm using USB audio capture since HDMI/DP audio doesn't work on Snapdragon
<HdkR>
Looks like we're missing something for performance on Oryon. It's losing to X13s in CPU bench
<HdkR>
Not in all microbenching, but it...probably shouldn't lose at all
frozen_cheese[m] has joined #aarch64-laptops
<frozen_cheese[m]>
good evening!
<frozen_cheese[m]>
I have a Yoga 7x I'm trying to get linux booted on but the only kernel I can get to start at all is qcoms custom debian kernel. None of the other kernels I've tried will get very far. There's about half a page of kernel messages before it crashes.
<JosDehaes[m]>
Rob's branch that he posted yesterday is probably best right now
<frozen_cheese[m]>
I'll take a look. I'm rebuilding AbelVesa's repo now
<frozen_cheese[m]>
if that doesn't work, I'll try Rob's
<steev>
not a snapshot of post 2.42?
<frozen_cheese[m]>
are you asking about the version in the initrd or the dev machine?
<steev>
the machine youre building the kernel on
<JosDehaes[m]>
Is this important?
<steev>
it can be yes, because there's a bug when RELR is enabled in the kernel and newer snapshots of binutils
<travmurav[m]>
HdkR: is that benchmark suite available somewhere?
<travmurav[m]>
ah
<travmurav[m]>
bytemark xD
<travmurav[m]>
I missed the line on the screenshot
<steev>
JosDehaes[m]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074111 there's the debian bug, and then in the debian bug - it looks like binutils has the fix as of 5 days ago, but debian unstable/testing don't have it yet
<JosDehaes[m]>
Thx, didn't have any issue, building on the yoga itself using latest Arch
tobhe_ has joined #aarch64-laptops
tobhe has quit [Ping timeout: 480 seconds]
jhovold has joined #aarch64-laptops
srinik has joined #aarch64-laptops
<jhovold>
steev: not sure what pci patches and soc you're referring to, but you haven't had to use powersupersave on the command line for a long time
<jhovold>
craftyguy: yeah, those USB errors during are annoying but mostly benign, tried to get qcom to address them when upstreaming support for the multiport controller, it's on the evergrowing list of things someone should look at
<jhovold>
during suspend*
srinik has quit [Remote host closed the connection]
srinik has joined #aarch64-laptops
srinik has quit [Ping timeout: 480 seconds]
<steev>
jhovold: i meant the disable pcie perst patchset, sc8280xp -
<jhovold>
steev: ok, no, that's just plugging a tiny current leak
f_ has quit [Ping timeout: 480 seconds]
<HdkR>
travmurav[m]: Yea, simple bytemark runs. I'll need to retest under WSL to see if there is a difference there
<travmurav[m]>
well.. beating oryon in whopping one category, and they dare to say 7c is bad /s
<HdkR>
Reasonable numbers for a Cortex-A76 based design
<HdkR>
No idea wtf is up with that string sort result though
<travmurav[m]>
yeah it was scheduled on one of the two phast cores
<travmurav[m]>
but also yeah
<travmurav[m]>
I guess might be something musl
<HdkR>
Could be
<HdkR>
stringsort spends most of its time in libc with memcpy, memcmp, memmove, and strncpy
<pstef>
does glibc have handcrafted assembly versions for those on arm64?
<HdkR>
Likely
<HdkR>
Yea, just pulled up the source. The implementations are in .S files
<travmurav[m]>
memcpy/memset in musl are also asm in aarch64 but perhaps not everything
<robclark>
probably the glibc version you have doesn't have oryon versions of memcpy/etc yet?
<travmurav[m]>
but seems like memcmp in glibc is like hundreeds of lines and in musl is like 3 xD
<HdkR>
Looks like there are memset and memcpy/memmove oryon1 specific variants in upstream glibc. but I wouldn't have expected such a significant difference from running the same implementation
<HdkR>
Updated my WSL ubuntu version to the same as non-wsl and the string comparison difference vanished luckily
<HdkR>
So then the issue is that running the same code, X1C at 3Ghz can beat the Oryon-1 at 3.4Ghz which is kind of sucky
<travmurav[m]>
hm I wonder at what power
<travmurav[m]>
and I guess they're putting like 12 of them instead of 4+4 a78 iirc?
<HdkR>
Yea, it's 3x4 Oryon1, versus 4xA78C+4xX1C in 8cxG3
<clover[m]>
6.10.0-0-x13s pushed to my arch repos
smpl has joined #aarch64-laptops
<steev>
\o/
<steev>
meanwhile, mr bleeding edge gpu stuff is chillin on 6.7
<pstef>
I've made the recovery image for my x13s, copied it to another device. Then - I don't know why - I decided to store tar-ed files instead of the image. Now I have all the files, but not sure how to turn this back into the bootable recovery image
<steev>
is it a directory of randomly numbered files?
<pstef>
no, it's "the original" structure with full names
<steev>
potentially... create a large efi partition and copy them onto it?
<FarchordSteveCossette[m]>
robclark: Hey rob, you said you booted Fedora on your asus laptop right?
<pstef>
steev: unironically, that hasn't crossed my mind. I convinced myself that the EFI has to be small and the 13 GB of Windows stuff has to have its own partition
<FarchordSteveCossette[m]>
Oh wait yoga nvm
nirik[m] has joined #aarch64-laptops
<robclark>
yeah, I've got the yoga.. but I guess the situation should be similar.. I dd'd a fedora raw img to the internal drive, played around with partition sizes, replaced kernel, etc
<robclark>
so somewhat of a manual install
<FarchordSteveCossette[m]>
robclark: Ah. I'm trying to figure out a way to build an image with the latest 6.11. It's being composed tonight but I think the flags are not enabled for what we need lol
<robclark>
yeah, I didn't try to use a fedora kernel yet
<robclark>
fedora's grub does work (but annoyingly keyboard input in grub doesn't... I guess my yoga has special efi somehow because afaiu it works for others)
* nirik[m]
ponders picking up a 7x now...
<HdkR>
Ubuntu's grub was bugged for me, I had to rip my old one off my X13s instead :D
<FarchordSteveCossette[m]>
nirik[m]: > * <@nirik:matrix.scrye.com> ponders picking up a 7x now...
<FarchordSteveCossette[m]>
Do you have time to play on it? XD
<robclark>
probably should work if you dd fedora image and then replace initrd+kernel+copy-/lib/modules/<kernelver>
<nirik[m]>
Yeah, time is the thing in short supply. New toys are fun tho...
<robclark>
HdkR: fwiw, I had same problem with shell.efi and systemd-boot
<HdkR>
Wacky
<FarchordSteveCossette[m]>
My family already thought I was being excessive with the amount of computers I have in my home lol
<robclark>
nirik[m]: if time is in short supply no harm in waiting.. things are moving fast and should be a bit smoother for end users later in the year once upstream stuff propagates into distro installers.. but if you do have time/interest in bringup now is the time ;-)
<robclark>
I can only say the # of computers I have is approximately an integer
<FarchordSteveCossette[m]>
robclark: 32b or 64b? lol
<robclark>
fortunately we don't need 64b to count them..
<FarchordSteveCossette[m]>
The integer I mean lol
<FarchordSteveCossette[m]>
lol
<FarchordSteveCossette[m]>
I'm a computer nerd, if money wasn't a problem I would have maaaany more
<HdkR>
At some point this stack of ARM devices is going to topple like a bookshelf in an earthquake
<nirik[m]>
yeah, looking like things will get enabled in the rawhide kernel in a few weeks anyhow...
<nirik[m]>
I have a... large amount of machines here too. ;)
<konradybcio>
robclark just admit how many non-integer devboards you have ;)
<robclark>
that would require counting them ;-)
<robclark>
maybe I'll make artwork from the armv7 ones
<HdkR>
Looks like the 806400Hz CPU clock speed is bugged and actually runs at full clocks even though it is reporting that speed.
<HdkR>
Walking through the other CPU clocks now
<JosDehaes[m]>
strongtz: looking at arch-image-builder to create bootable media, seems pretty sweet. Is there a way to add binary files (like kernel/dtb)? It seems you have to specify the contents inline
<steev>
clover[m]: ^
<agl>
clover[m]: Do you Update the Kernel for your endeavourOS arm?
<clover[m]>
Yes, this morning
<agl>
Ok
<agl>
6.10 ?
<agl>
clover[m]: which version? 6.10?
<agl>
clover[m]: I have looked. It’s 6.10. Thank you!
<HdkR>
Oh, it wasn't explicitly about 806Mhz. I ran through the list of frequencies, and then went back to it and numbers fell in line. So it looks like selected frequency isn't always sticking?
<pstef>
steev: that was it, it works, thanks! Now my "optimization" makes more sense
<steev>
oh, nice haha
<steev>
robclark: if you happen to know... vulkaninfo reports VK_EXT_memory_budget : extension revision 1; but doesn't seem to show VkPhysicalDeviceMemoryBudgetPropertiesEXT - are they different? (or is my mesa just too old?)
<robclark>
steev: I think tu has a trivial implementation of the ext (not sure anything more makes sense for an igpu without vram)
<steev>
i just wanna run ollama on the gpu or npu, though even on cpu it's not terrible, and honestly, the memory is the bigger issue
<steev>
i could probably pull that pr in, and then hack out the check for that extension
<steev>
it looks like it's just using that ext to get how much memory is available
smpl has quit [Ping timeout: 480 seconds]
<FarchordSteveCossette[m]>
Hey guys so i got a 6.11 image of fedora. I modified the launcher conf to add the vivobook dtb but now i get stuck in a black screen
<FarchordSteveCossette[m]>
Am i maybe forgetting something?
<FarchordSteveCossette[m]>
Im also booting from a usb-c drive, if it matters