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)
<HdkR>
hm, grub_calloc not found then unknown filesystem, rude
<HdkR>
ah, root= needs to be correct I think
<szclsya[m]>
also you should use partuuid rather than uuid because kernel won't recognize filesystem uuid without initrd, as steev suggests
<HdkR>
oh right, been a long time since I touched the c630 so I forgot about that
<HdkR>
HDK board just uses fastboot which has its own set of terrible problems
<HdkR>
Hm, immediately explodes when exiting boot services
<clover[m]>
Today's image adds a kernel option to disable the noisy audit output
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<steev>
nice
<steev>
bamse: does b4 pick up T-b on the 0/X or should i send them to X/X ?
<HdkR>
Jeez, the x13s has to have the smallest speaker wires ever
<steev>
just stop having fat fingers? :P
<HdkR>
Plugging them back in after fiddling took a little bit of tweezering
<steev>
heh
<HdkR>
Putting the back cover back on
<steev>
i appreciate you taking the back off
<szclsya[m]>
the speaker is pretty neat tho, probably the best I've heard so far within windows laptops
<HdkR>
Watch out for breaking off the tabs on the back cover. I definitely snapped one
<HdkR>
Quite fragile
<szclsya[m]>
authentic lenovo experience
<steev>
we're finally reaching feature parity with x86_64!
<HdkR>
How do I tell if the battery is charging on this thing?
<HdkR>
There isn't a /sys/class/power_supply/ that I can see
<szclsya[m]>
I think that isn't implemented yet
<HdkR>
Hope and pray it is charging
<steev>
HdkR: when you plug it in, the led near the power button will blink 3 times
<HdkR>
ah, I saw it
<steev>
qzed: for completeness... it also works on the c630. so c630, flex5g and thinkpad all show the efivars
<HdkR>
https://browser.geekbench.com/v5/cpu/16138637 Since we're posting geekbench numbers. Think this confirms that there is something wrong with my 888 board, probably cache related
<janrinze>
HdkR: at which part of the globe are you located?
<HdkR>
US
<janrinze>
west coast?
<HdkR>
Correct
<janrinze>
Do you guys buy online from lenovo or through resellers?
<HdkR>
This was direct from Lenovo
<janrinze>
Okay, understood.. Wonder how that will fare from Europe..
<janrinze>
i feel that the lenovo has a high price tag because of the win11 license.. right?
<szclsya[m]>
HdkR: I see FEX in the cpu model. that's a x86 emulator.
<HdkR>
That it is
<szclsya[m]>
then it's emulating x86? that would explain the low score
<janrinze>
Orin just became available here but that price tag...
<HdkR>
Then I'm a bit disappointed that the perf difference isn't more
<janrinze>
it costs more than a Mac studio!
<HdkR>
Xavier means JITs stacking JITs, which isn't very good
<janrinze>
Carmel does some JIT but it does it in hardware..
<HdkR>
aye, in MTS
<HdkR>
Which is still a JIT :P
<janrinze>
basically it can do really great performance if the code is aligned for the JIT
<janrinze>
most compilers don't. I think clang >12 can optimize a bit for Carmel
<HdkR>
oh neat, The 8CX G3 SoC isn't just shipping X1 and A78. It's shipping A78C and X1C
<janrinze>
Orin is A78C, right?
<HdkR>
A78AE
<janrinze>
Orin has max clock to 2.2 GHz so no competition..
<janrinze>
NVidia probably should have done X1C instead
<HdkR>
Clock speed is a bit sad. I assume it can't quite reach as high clocks due to lockstep requirements
<janrinze>
hm.. indeed.. the lockstep choice was for automotive, right>
<HdkR>
Correct
<szclsya[m]>
HdkR: what's the difference between X1 and X1C? higher cache?
<HdkR>
PAC, More L3 cache supported
<szclsya[m]>
ah
<szclsya[m]>
pointer authentication doesn't work for now though, I think there is a patch in the tree to bypass pa init because it hangs the kernel on booy
<HdkR>
Oh well. I'm more interested in MTE anyway :P
<janrinze>
HdkR: why is the 888 running in emulation?
<HdkR>
They both are!
<janrinze>
possibly memory bandwidth limited.. JIT requires big cache too
<HdkR>
Yea, bigger bandwidth numbers likely help but I also am not sure if the 888 board's kernel is healthy
<janrinze>
HdkR: did you builld the kernel or is it the one that came with the board?
<HdkR>
It's a built kernel
<HdkR>
Pretty old at this point though
<janrinze>
on the AGX: hikey970.local 4.9.140OES-KVM-32.4-deadline+
<janrinze>
the OES kernel tree at least has some decent patches for the AGX. Haven't gotten around to getting the later kernels installed..
<janrinze>
The AGX has served me well as a Linux Desktop. specifically the OpenGL support is great
<janrinze>
I'm sure purists will hate the blobs required for the GPU..
<HdkR>
My xavier boards are still on vendor kernel, can't wait to rip those out and replace with Orin
<janrinze>
HdkR: only with unlimited funds it would be an option for me ;-)
<janrinze>
HdkR: did you use CUDA on those too?
<HdkR>
:D
<HdkR>
nop
<HdkR>
CPU testing only
<janrinze>
I tried but noticed the memory layout issues and the delays.. my video processing works better cpu-only.. it's latency that keeps me from using CUDA
<janrinze>
in Geekbench there are at least 4 different Lenovo spadragon 8cx gen3 platforms..
<janrinze>
snapdragon.. oops..
<HdkR>
If someone can solve bringing the GPU online with the X13s before I look at it again in 18 hours that would be great :)
matthias_bgg has joined #aarch64-laptops
<HdkR>
GPU is the last thing I need for it to be a development focused device...I think?
luxio_39[m] has joined #aarch64-laptops
<HdkR>
I'd guess some people might complain about lack of audio but eeh
<jhovold>
steev: b4 can pick up tags/trailers posted in reply to the cover letter
iivanov has joined #aarch64-laptops
iivanov__ has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
<javierm>
jhovold: interesting. And it does apply to all the patches in the series?
<jhovold>
javierm: indeed
<javierm>
jhovold: cool. I don't think that patchwork does the same when one downloads a complete patch series
<javierm>
it would be great if it did so that you only need to git am that
<javierm>
should look at using b4 instead of plain pwclient / patchwork
iivanov__ has quit [Ping timeout: 480 seconds]
matthias_bgg has quit [Ping timeout: 480 seconds]
matthias_bgg has joined #aarch64-laptops
<jhovold>
steev: (and anyone else using the wip/sc8280xp-20220714 branch for X13s), please update to the following branch which has a few important revert of PHY commits in linux-next that broke USB and PCIe on an SA8540P machine and that could cause trouble on X13s as well: https://github.com/jhovold/linux/commits/wip/sc8280xp-20220720
<jhovold>
steev: this branch should also address the warnings for any non-populated HID devices
djakov has quit [Remote host closed the connection]
djakov has joined #aarch64-laptops
<qzed>
steev: thanks for testing! I'll let you know once I have some patches for the kernel
<steev>
jhovold: thanks for the heads up, i'll give it a whirl
Sobek[m] has joined #aarch64-laptops
<steev>
qzed: if we CAN get that in, it means all the hacks like dtbloader can go away
<qzed>
dtbloader? what?
<qzed>
can you just set some efi variable and the kernel loads the DTB from that?
<steev>
hm, or maybe it's not sufficient to have efivars
<qzed>
I have no clue
<robclark>
yeah, it looks at hw id and picks which dtb to load based on that... ie. so you can have a single disk or installer img that works on different laptops w/ different dtb
<qzed>
so with support for efi vars that could be done in kernel?
<robclark>
it is orthogonal to support for efi vars
<robclark>
(although efi vars are nice so you can control boot order, etc)
<qzed>
right
<robclark>
dtbloader runs before ExitBootServices (ie. when efi vars work already)
<qzed>
that's one reason I'm working on that... other is I hoped I could figure out why ResetSystem doesn't work
<qzed>
yeah, I'm just wondering because steev mentioned support for efivars would eliminate the need for dtbloader
<steev>
i *thought* it would
<steev>
keep in mind that i'm a step up from mentally deficient
<qzed>
I guess with efivars accessible to the kernel you could move the stuff that dbloader does to the efistub
<qzed>
whether you'd want to do that is another question
<qzed>
I mean it would be kinda nice to shove a full dtb into efi somehow, but I think that'll be too big for efivars
<qzed>
steev: aren't we all?
<steev>
i just stand on the shoulders of all you giants, pulling in random patches that i read and say "yeah, i have that problem" and then people wanna use my kernel tree for some reason
<robclark>
I suppose you could use an efivar to store _which_ dtb to load.. but I think grub or something else could always implement the same CHID method to pick dtb
<robclark>
the grand idea for DtbLoader was it could be something you install and then device boots according to arm's EBBR spec (more or less).. without having to do grub/etc hacks.. and then updated dtb for new devices could just be treated as a fw update w/ fwupd
<robclark>
but I guess I'm the only one who thought it was a good idea to make these things look like they followed some kind of standard ;-)
<qzed>
nah, I think that's likely the proper way to address that and make it more user-friendly
<steev>
i like it... i just dislike the extra shell step
<steev>
efi shell... leaves a lot of shell to be desired
<qzed>
I'm at the moment just too lazy and changing dtbs too frequently to give it a spin
<robclark>
yeah, no one every really got around to making the DtbLoader install step a bit more polished.. I agree that having to drop to efishell is not a great UX ;-)
<javierm>
robclark: maybe one option could be for DtbLoader to just rely on the EFI Default Boot Behaviour and attempt to boot \EFI\BOOT\BOOTAA64.EFI ?
<javierm>
that way you could just have an efivar that points to DtbLoader and make that the first in the BootOrder
<javierm>
althought that's a big change in behaviour since currently it doesn't do anything more than loading and registering the DTB...
<robclark>
I thought I had a branch somewhere that turned it into a shim instead of a driver..
<robclark>
in the end, it isn't really a whole lot of code, so that seems like it would be an option.. esp if userspace could set efi vars
<robclark>
hmm, if I did, I didn't push it anywhere
<steev>
relatable
<javierm>
robclark: exactly, that's what I thought. Using efibootmgr to create that EFI boot variable and then forget about it
<javierm>
you just need a LoadImage() from a hardcoded location + StartImage()
<steev>
jhovold: 20220720 is v unhappy with my wifi
<jhovold>
steev: bah, I see it here too. Didn't expect that much to break in next this close to the merge window when rebasing on next 6 days later. Looks crypto related. Will take a look at it tomorrow. But perhaps you should use your old 5.19 branch until then. Sorry about not noticing.
<jhovold>
steev: perhaps the crypto thing was unrelated, selftest thing
<steev>
jhovold: oh yeah, the crypto thing is unrelated
<steev>
just the wifi
<steev>
the crypto thing is because of my config. haven't poked at it to see what exactly is going on there (and again, i'm bad with maths)
<HdkR>
Will upgrade to that in a bit, it apparently took all night for it to fail though
<HdkR>
Looks like suspend happened and it might have caused problems
<steev>
oh
<steev>
yeah, suspend is known broken
<HdkR>
Looks like I can kill autosuspend
<steev>
yeah, you can; though you might want to also do "su - gdm -s /bin/sh" and then "GSETTINGS_BACKEND=dconf gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'" then restart gdm3
<steev>
that will make it so if you ever reboot and let it sit at the login screen, it won't suspend either
<clover[m]>
how tough will it be to get suspend working?
<HdkR>
destroyed it
<steev>
i couldn't tell you, but i know it requires pcie and usb work
systwi has quit [Ping timeout: 480 seconds]
<clover[m]>
do other aarch64 laptops support suspend?
<clover[m]>
like the C630
<steev>
yes
<steev>
though it's not as deeply suspended as it could be
iivanov has quit [Remote host closed the connection]
iivanov has joined #aarch64-laptops
<HdkR>
Alright, got the rc7 kernel built
<HdkR>
ah, gpu not even defined in the DTS currently
iivanov has quit [Ping timeout: 480 seconds]
<HdkR>
Welp, that's far outside what I can do. So I'll leave it there for now.
<steev>
HdkR: yeah, bamse linked the downstream kernel yesterday or the day before that has a690 support
<steev>
i've cloned it, but i haven't looked at all
<HdkR>
Will take a peek, hopefully copy and pasting some garbage will work :P
<steev>
qzed: indeed, built in, it does mount the efivars automagically
<qzed>
apparently it's systemd that mounts them and if that stuff is built as module it probably gets loaded too late, but if it's built in it seems to work fine