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
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
mjeanson has quit [Remote host closed the connection]
shoragan has quit [Read error: Network is unreachable]
shoragan has joined #aarch64-laptops
shoragan has quit []
shoragan has joined #aarch64-laptops
mjeanson has joined #aarch64-laptops
davidinux is now known as Guest881
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
whiskey9 has joined #aarch64-laptops
whiskey9 has quit [Quit: whiskey9]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
tobhe has joined #aarch64-laptops
tobhe_ has quit [Ping timeout: 480 seconds]
enyalios has joined #aarch64-laptops
enyalios_ has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
deathmist1 has joined #aarch64-laptops
deathmist has quit [Read error: Connection reset by peer]
<jhovold>
a lot of that works is now being leveraged for the x1e laptops, but there are still bits missing bugs that need to be squashed
<jhovold>
that said, the x13s is in a pretty good state now, and work done on for example the suspend power consumption will benefit the x13s as well as x1e
<jhovold>
rsalveti: yeah, not sure exactly what is causing EBS() to fail on the t14s, but it's definitely a firmware bug that lenovo/qcom needs to fix
<jhovold>
afaiu, the (second) EBS() call should not be allocating memory, but it currently is and that makes things fail
<jhovold>
I may have found a workaround on Friday, by patching the EFI stub, but I need to spend some more time on verifying that
<jhovold>
either way, such workarounds would not be welcome upstream, so we still need lenovo/qcom to fix this
chrisl has joined #aarch64-laptops
<macc24>
SpieringsAE: in honor magicbook 14 i see only qualcomm signatures in qcav1e8380.mbn
<JensGlathe[m]>
We could binary compare
chrisl has quit [Ping timeout: 480 seconds]
<kalebris>
sleep improvements, like reach the lower power states, or is there some hibernate effort as well?
krzk has quit [Quit: leaving]
davidinux has joined #aarch64-laptops
Guest881 has quit [Ping timeout: 480 seconds]
chrisl has joined #aarch64-laptops
chrisl has quit [Ping timeout: 480 seconds]
davidinux has quit [Quit: WeeChat 4.3.1]
vickdu31[m] has joined #aarch64-laptops
<tobhe>
I wonder if it would make a difference if we RaiseTPL(TPL_NOTIFY) before exit_boot_services to make sure there aren't any timers interfering
* travmurav[m]
immediately remembers some firmware crashing when one tries to raise tpl at all
<travmurav[m]>
I think it was 7c tcl but still
<JensGlathe[m]>
I guess we‘ll find out
<tobhe>
TPL_HIGH_LEVEL sounds even better
whiskey9 has joined #aarch64-laptops
davidinux has joined #aarch64-laptops
enyalios_ has joined #aarch64-laptops
enyalios has quit [Ping timeout: 480 seconds]
abcdw has quit [Remote host closed the connection]
kuruczgy has quit [Remote host closed the connection]
krzk has joined #aarch64-laptops
abcdw has joined #aarch64-laptops
kuruczgy has joined #aarch64-laptops
<kuruczgy[m]>
I am wondering if it would be worth to play around with virtualization, and I have some questions:
<kuruczgy[m]>
- Has anyone tried slbounce on the slim7x yet? How much hw support do we lose when booting in EL2?
<kuruczgy[m]>
- How far away is drm native context from working, has anyone tried it on x1e already?
<maz>
jhovold: could you describe the nature of your potential stub workaround?
<rsalveti>
jhovold: interesting, can you share the workaround? I'm raising this issue internally at qcom
chrisl has joined #aarch64-laptops
krzk is now known as Guest964
Guest964 has quit []
krzk has joined #aarch64-laptops
<jhovold>
maz: I tried signallig EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES before getting the memory map and that made things work with both grub and sd-boot
<jhovold>
however...
<jhovold>
just doing the event allocation, without actually signalling anythig, also makes things work
<jhovold>
so perhaps it's just working by chance, by altering timing or alignment or something
chrisl has quit [Ping timeout: 480 seconds]
<jhovold>
rsalveti: it's still very early, but I expect to include something like this in my next wip branch
<jhovold>
I'll try to spend some more time on this and post something a little more polished soon
<jhovold>
tobhe: I tried raising tpl too, but that made no difference
<jhovold>
maz: you said you managed to get things to work with shell scripts on the devkit, right?
<jhovold>
I tried starting the kernel from startup.nsh but that also fails here
<jhovold>
But running the exact same script from the shell manually works...
chrisl has joined #aarch64-laptops
<macc24>
travmurav: idk why but 7c feels to me like a chip exclusively found in chromebooks
<macc24>
i wonder why there were no qcom chromebooks after sc7180 and sc7280
<Jasper[m]>
macc24: Nah
<Jasper[m]>
Same for sc7280
* travmurav[m]
looks at his 7c woa laptop
<Jasper[m]>
I'm going to guess no sc7280 (or newer) chromebook came out because of a spat Google had with Qcom
* travmurav[m]
<del>also looks at Jasper 's 7c3 he never ever finished trying to boot linux on</del>
<Jasper[m]>
Also, the fact that some part of the team got axed
<Jasper[m]>
@travmurav there's also the Ocean Plastic™ Lenovo 10W
<macc24>
Jasper: yeah that'd sound about right for qcom
<travmurav[m]>
but probably because the 7c1 was quite more fitting for cros than for woa
<Jasper[m]>
YES, GOD YES IT IS
<Jasper[m]>
Even the SC7280 is barely acceptable, most of it is due to UFS
<macc24>
travmurav[m]: why?
<travmurav[m]>
¯\_(ツ)_/¯
<Jasper[m]>
My fulltime job and other distractions
<robclark>
kuruczgy[m]: drm native context should "just work" .. I haven't gotten around to trying it on x1e yet, but it worked (after spending too long figuring out magic qemu cmdline) on x13s. At the time I still needed some qemu patches but I think they should probably have been merged by now. I can dig up the branch and qemu cmdline a bit later today
hogliux has joined #aarch64-laptops
<Jasper[m]>
But since I'm nearly stuck with Pixel C again, it's almost time for project roulette again
<hogliux>
kuruczgy[m]: I have EL2 working on slim 7x. See my messages from yesterday.
<hogliux>
kuruczgy[m]: I'm booting via slbounce. GPU acceleration also works as long as you remove the zap shader from the dtb
<robclark>
macc24: sc7280 was unfortunate timing vs market conditions .. _current_ x1 things are still a bit too expensive for chromebooks.. we'll see what the future brings
<hogliux>
kuruczgy[m]: but anything relying on DSP won't work: battery, Bluetooth etc.
<maz>
jhovold: the trick for me was to *not* use the built-in shell, but the EDK2 version instead.
<maz>
so my bootaa64.efi binary is actually a shell, and startup.nsh does the work of loading slbounce, an ext4 driver, finding the partition on which my kernels are, and pick the most recent one.
hogliux has quit [Remote host closed the connection]
alfredo has joined #aarch64-laptops
<kuruczgy[m]>
robclark: Thanks, and it's also good to know that qemu should work and I don't need crosvm. (The qemu cmdline would also be appreciated if you still have it :) )
<robclark>
oh, edk2 has ext4? That was like the main reason for grub to exist
<robclark>
kuruczgy[m]: yeah, I should still have it.. but it's on my x13s I think
<kuruczgy[m]>
@hogliux: thx, good to know. Not having a battery indicator sounds like a big pain point... Are you sure about bluetooth? Isn't that a separate device over uart? Why does it need dsp?
<jhovold>
maz: were the symptoms similar otherwise, with EBS() failing?
<jhovold>
it may help if we could point qcom to a board with a serial port where this could easily be reproduced
<robclark>
kuruczgy[m]: ok, so here is the branch that I was using at the time (based on some wip stuff from digitex)... I've not tried to rebase it yet, but that might be useful as a reference
alfredo has quit [Quit: alfredo]
<kuruczgy[m]>
robclark: hm where is the branch? In the paste I only see the cmdline
<kuruczgy[m]>
travmurav: I am looking through the slbounce repo right now, do you mind if I open issues for a couple observations I am having, so I don't forget about them? (E.g. gnu-efi seems to have moved to github, I think the link should be updated in .gitmodules. Also I see a line `ln -sf /usr/include/elf.h ...` in the Makefile, I don't think this will work on non-FHS distros.)
<travmurav[m]>
kuruczgy: yeah feel free to do so. The elf thing is a dirty hack fwiw
<ppd[m]>
kuruczgy: hey, I should ask. rl bogging down work on the config for you too? i've gotten bogged by college myself, so I imagine it's the same for you
<travmurav[m]>
kuruczgy: it's possible that slbounce needs to be heavily refactoring and perhaps moved to clang (which is much less annoying to build .efi in it seems) but at this moment I kinda don't want to breathe at it too much 😅
<travmurav[m]>
I will leave myself a todo note to look and fix the gitmodules tomorrow (will probably keep the same tag for now) and maybe look again why it depends on elf header
<ppd[m]>
i'm only bringing this up because I have stalled on the audio config stuff but that's due to aforementioned
<rsalveti>
jhovold: atm we're trying to identify if this firmware issue is specific to the qcom release or by the modifications done by the vendor, so it would be nice to know if it is also reproducible on other hw platforms
<rsalveti>
I only got t14s with me
<kuruczgy[m]>
ppd: I don't have a full-time job right now, so I do have _some_ time to work on it. I think progress is just slower since all the low hanging fruit has already been picked. But I do plan on at least lurking in this channel and picking up any any new hw support that appears for the foreseeable future.
<JensGlathe[m]>
rsalveti: HP Omnibook X14 has a similar issue, but I get it booted reliably from internal SSD with grub. Booting with the same grub from type-c gives you a stuck keyboard, it will boot the default after timing out.
<jhovold>
rsalveti: I haven't had any similar issues with the crd (only been using grub), but it sounds like maz may have run into this with the devkit as well
<ppd[m]>
kuruczgy: that's kinda what I figured as well
<kuruczgy[m]>
ppd: That's fine. Tbh for me audio is quite low priority since I am perfectly fine with my bluetooth speakers/headphones.
<ppd[m]>
tbh I really wish I had like a bt multiplexer myself but it's fine
<maz>
jhovold: yup, EBS, hard reset, the works.
<ppd[m]>
what I want to do for the memes is run warframe on this laptop, no matter how bad it is
<maz>
the devkit is certainly the easiest reproducer here.
<ppd[m]>
I just want a frame of output :D
<jhovold>
but the t14s doesn't hard reset, EBS just fails and you're back in the boot menu
<ppd[m]>
but irl I am actually quite fond of it
<jhovold>
in grub you lose keyboard, but keyboard works in sd-boot
<jhovold>
after such a failure
<maz>
with grub, I wasn't even coming back to the menu. a bit ASSERT() from the firmware, and usually a hard reset after a few seconds.
<maz>
big*
<kuruczgy[m]>
ppd: Is it FOSS, or using fex-emu? I actually expect x86 games to run pretty well once the whole emulation stack is put underneath them.
<kuruczgy[m]>
(e.g. fex-emu + wine + possibly a VM with drm native context)
<ppd[m]>
I haven't tried it yet, mostly because I wanted to do audio first and get that working "well"
<ppd[m]>
plan was to try box64 when that got x86 emu support but I could use fex too
<ppd[m]>
iirc I remember hangover being a thing too
<robclark>
kuruczgy[m]: no need for VM like on apple.. only reason asahi needs a VM is because host kernel is using 16K pages
<robclark>
so just need fex-emu and proton (which I guess is packaged in the fex-emu rootfs)
<kuruczgy[m]>
robclark: I know, but while I am at it I might as well try setting it up, all the tech should in theory be there, and AFAIK drm native context has negligible overhead. I would sleep better at night knowing that my games run isolated from the rest of the system and can't touch anything important. (Like on ChromeOS.)
<travmurav[m]>
Eh it's the same linker conversion mess as gnu-efi
<travmurav[m]>
And I guess this also doesn't spit out .pdb for debugging
<travmurav[m]>
Which was actually kinda useful at some point in dtbloader
<anonymix007[m]>
At least there's no need for uefi_call_wrapper somehow
SpieringsAE has joined #aarch64-laptops
<travmurav[m]>
Uefi call wrapper is transparent on arm anyway I think
<robclark>
kuruczgy[m]: fair.. but cpu governor for guests is a pain.. CrOS had some downstream patches to implement a virtual cpufreq governor in the guest which mapped to uclamp tuning in the host. (There was some discussion about this upstream, but idk if it went anywhere.) You can kinda work around it by just using performance cpufreq governor and not caring about battery life (AFAIU this is what asahi is doing)
<travmurav[m]>
I think it's just some calling convention stuff, which probably just set properly on the compiler
<SpieringsAE>
I have a question about submitting, so I submitted a patch series, 4 patches, one of them got accepted, but I need to post a new version of the other patches
<robclark>
kuruczgy[m]: I was fairly involved in the arcvm performance work on CrOS ;-)
<SpieringsAE>
I should drop that specific commit now right?
<anonymix007[m]>
travmurav: Yeah, it shouldn't be needed on arm afair
<kuruczgy[m]>
robclark: I see, thanks for the heads-up :)
<travmurav[m]>
anonymix007 But well, build time wise I like clang+lld-link for just spitting out a fully proper PE and all the pdbs: can addr2line, can check generated code in ghidra...
<anonymix007[m]>
Well, "native" PE builds have some advantages obviously. Not sure if it is worth building clang though as it usually targets native elf in most distros
SpieringsAE has quit [Remote host closed the connection]
<travmurav[m]>
Building clang?
<anonymix007[m]>
Hmm, I'm quite sure addr2line would work with elf2efi as well, the original .elf should just have all the symbols
<travmurav[m]>
Aarch64 pe triplet was just there on all distos I've checked so far :p
<travmurav[m]>
I had an impression that copying stuff around from elf to pe breaks some offsets, at least i do t think they matched last time I tried
hightower2 has quit [Read error: Connection reset by peer]
hightower2 has joined #aarch64-laptops
<travmurav[m]>
Perhaps it was objcopy and the funny script does something (smarte|dumber)
SpieringsAE has joined #aarch64-laptops
JulesA has joined #aarch64-laptops
JulesA has quit [Quit: Leaving]
<JensGlathe[m]>
Does anybody know what GIO offset 0x03C0 from ACPI is on x1e? Usually the touchpad has 0x380 and translates to gpio tlmm 3
<JensGlathe[m]>
but the Acer Swift 14 has a different one. I2C0 Address 0x68, and this odd GIO offset
<SpieringsAE>
for me the GIO pin list number matches the tlmm gpio number, but that one is above the number of tlmm gpios
<JensGlathe[m]>
I know, so its an odd translation
SpieringsAE has quit [Remote host closed the connection]
<kettenis>
on the yoga 0x3c0 is the touchpad and maps to pin 3
<kettenis>
on the galaxybook it seems to be the touchscreen and I'm not sure we've figured out yet what tlmm pin it maps to
<vickdu31[m]>
On the acer, it seems to be the touchpad
<kuruczgy[m]>
travmurav: What's the procedure for extracting tcblaunch.exe from Windows? Also, do you know how much it varies between devices (e.g. is it the same for everyone, or does it vary by SoC, or even by device?)