robclark 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
<Segfault[m]> wow, i just tried to boot my x13s for the first time today and it had three hard resets in a row when trying to start the gpu
<robclark> would be nice if we had console-ramoops to capture dmesg before the reboot, but IME insta-reboots point at some clk issue (ie. driver thinks the interface clk is on and tries to access regs but they are unclocked)... that said, I've not seen this issue (although I'm still using clk_ignore_unused because AFAIU it is still needed for other reasons)
<robclark> access to unpowered blks can be same issue, ie sync (read) or async (write) external abort => some tz or hyp thing traps that and insta-reboot..
<robclark> (but I also still have pd_ignore_unused)
<Segfault[m]> i'm using clk_ignore_unused and pd_ignore_unused as well, it could be related to my system loading msm later than normal because it's not in my initramfs and i have FDE enabled
<robclark> hmm, I think in my case it is in the initramfs.. but not all the needed fw is. Which means display will come up but not gpu (although in both cases it should be after lateinitcall so I can't think of a particularly good reason why the timing difference would matter.. but there are a lot of moving parts when it comes to dependencies on clk/pd/icc/etc)
<Segfault[m]> <robclark> "Segfault: a slightly better..." <- yep that works
<robclark> \o/
louist103 has joined #aarch64-laptops
<louist103> Hey all, me again. I followed all the x86_64 steps and got it installed but the laptop doesn't see the drive to boot off of. I did it on an external NVME drive. Not sure if that isn't supported. it looks like the windows partitions use GPT and EFI so the system should be able to boot it. This is the C630
<louist103> Secureboot is off and USB Boot is on in the BIOS
<steev> do you have the usb modules in your initramfs?
<louist103> I'm not sure but it doesn't even get that far
<louist103> The BIOS isn't even seeing it. It only sees the builtin drive
<louist103> it may also help to add I get this when doing the normal grub-install
<louist103> livecd / # grub-install --efi-directory=/efi Installing for arm64-efi platform. EFI variables are not supported on this system. EFI variables are not supported on this system. grub-install: error: efibootmgr failed to register the boot entry: No such file or directory.
<louist103> but when I add --removable it runs fine but still wont show up
<louist103> I guess a good question would be how is the gentoo-minimal install CD set up? Is it BIOS or uEFI?
louist103 has quit [Remote host closed the connection]
<steev> oh wait, what size
<steev> ah damn, he's gone
<steev> iirc, the c630 won't boot from > 32GB on usb, if you're using the latest bios
louist103 has joined #aarch64-laptops
<louist103> @steev I'm back (and read the history) its a 256 GB drive
<louist103> If its impossible for USB I'll just image the original SSD and install on that
<steev> yeah, that probably won't work; unless... one thing i used to do, that was terrible, was a 32gb in one port, 256 in the other
<steev> and then boot it that way, and yank the 32gb out after booted
hexdump0815 has joined #aarch64-laptops
<steev> just had to remember to keep them in sync
<louist103> I don't want windows *that* bad on there. Arm windows is limited enough as it is
<louist103> At least I know its *probably* not something I did wrong.
<steev> eh, arm windows isn't that bad on the x13s, i didn't even mind it too much on the c630
<steev> it's *probably* not, it just hit me wehn you mentioned it
<steev> somewhere in the lenovo forums i have a post begging them to revert that change
<steev> but they abandoned the c630 and never responded to my post
<travmurav[m]> can you just partition the usb stick to be 4GiB or it checks the raw disk size itself? :/
hexdump01 has quit [Ping timeout: 480 seconds]
<travmurav[m]> ah, install to an external nvme
<travmurav[m]> I see
<louist103> yeah it booted a 4GB installer fine. Though I HAD to flash it on a linux machine, rufus wouldn't boot at all
<louist103> Are you saying to partition the drive to be 32 GB and leave the rest empty?
<louist103> Oh yeah speaking of that I couldn't get it to ever boot off something plugged into the left side. Only the right side would boot.
<travmurav[m]> I thought the goal is to install the system using an installer on a big drive, not that one can't boot an os /installed/ to a big external drive :/
<steev> they've completed the install step, it's the boot step they're having issues with
<louist103> Yeah its installed on the big drive.
<travmurav[m]> yeah missed that the first time reading the backlog
<louist103> and of course windows still not able to boot off of USB*
<louist103> It could also have been the PMBR warning fdisk was giving. Not really easy to know at this point
<louist103> Though only fdisk on the gentoo installer had the warning. gdisk on the installer was fine, and fdisk -l on my other linux laptop was fine.
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
craftyguy has quit [Remote host closed the connection]
craftyguy has joined #aarch64-laptops
louist103 has quit [Remote host closed the connection]
mcbridematt has quit [Read error: Connection reset by peer]
<lun[m]> What's required for the QCOM_PD_MAPPER to work and replace the userspace version?
<lun[m]> * What's required for the QCOM_PD_MAPPER module to work and replace the userspace version?
<steev> lumag to have time to fix it
Lucanis has quit [Ping timeout: 480 seconds]
<Segfault[m]> has anyone tried slbounce on an X13s recently? i did get linux to start booting with it but the ssd never seemed to show up and after a few seconds the screen went black for some reason
<travmurav[m]> pcie doesn't work and need fixes when running in el2
<travmurav[m]> and for display, probably need to kill the zap shader
<Segfault[m]> i was using dtbhack.efi so that should be handled
<Segfault[m]> also in the initramfs i don't think i have the msm module so that shouldn't have caused the screen to go black anyway
<travmurav[m]> I won't be surprised if it died because linux disabled unused clocks
<travmurav[m]> so loosing display without ever loading msm sounds normal to me
<Segfault[m]> i've got clk_ignore_unused and pd_ignore_unused set too :P
<travmurav[m]> fun
<travmurav[m]> but i believe the display worked fine for people testing it so far
<jhovold> something needs to keep the display regulators enabled, otherwise they are disabled after a 30s timeout
<jhovold> i think there was a switch merged recently to disable that timeout
<jhovold> otherwise you need a display driver in your initramfs
<jhovold> (or patch the devictree to mark the regultors as always on)
Lucanis has joined #aarch64-laptops
<Segfault[m]> oh, pd_ignore_unused doesn't apply to regulators does it...
<Segfault[m]> fair enough i guess
<Segfault[m]> i'm surprised i don't hit the same timeout when booting normally
<travmurav[m]> probably msm has time to load in those 30 seconds and assert the regulators
<Segfault[m]> oh LMAO, i DO hit the same timeout when booting normally, i've just never waited that long to put in my password
<javierm> jhovold, Segfault[m]: since v6.8-rc1, there's a regulator_ignore_unused
<jhovold> javierm: thanks, I know you posted that recently
<Segfault[m]> ah cool i'll keep that in mind, although with no pcie this isn't going to boot anyway so i'll keep experimenting with that later if it ever gets fixed :P
<travmurav[m]> can still boot from usb if you /really/ want to :P
<jhovold> Segfault[m]: this was one of the topics I covered in my presentation at kernel recipes (and using full disc encryption as an example)
<Jasper[m]> <travmurav[m]> "but i believe the display worked..." <- Yep, but I have the panel and gpu related modules in my initramfs
<Segfault[m]> jhovold yep i saw that and was just thinking about it lol
<travmurav[m]> afaiu current two problems are: pcie iommu crashes the system in a mysterious way if enabled, and making remoteprocs work (shouldn't be too hard to fix)
<Segfault[m]> booting in el2 might be useful for debugging the venus stuff, i think the hard resets from that are caused by the hypervisor so without it there it might be possible to get logs?
<jhovold> it's also mentioned in the commit message for johan_defconfig: https://github.com/jhovold/linux/commit/e6afa0380b4915646a07306d706f6337f40fef90
<jhovold> Segfault[m]: ah, cool
Caterpillar has joined #aarch64-laptops
<Segfault[m]> and yeah i did used to have an initramfs with all the relevant modules but i did a reinstall on rawhide recently and never got around to configuring that bit because for the most part it worked fine as is
<HdkR> 11
<Jasper[m]> What is the current release of Microsoft Windows
shoragan has quit [Read error: Network is unreachable]
shoragan has joined #aarch64-laptops
shoragan has quit [Read error: Network is unreachable]
shoragan has joined #aarch64-laptops
<jglathe__> Windows 11, version 23H2 (22631.3155) arm64
<jglathe__> try to find the version if you're booted into linux, interesting
<Jasper[m]> jglathe__: Hah, yes. But it was more of a Jeopardy style answer to what @HdkR said
<Jasper[m]> jglathe__: uupdump is good for that, especially if you need an arm64 recovery image for devices that don't have them
<Jasper[m]> (in combination with the driverfetch functionality of uupmediacreator)
pneuhardt has joined #aarch64-laptops
<jhovold> Segfault[m]: have you noticed any improvement wrt to ath11k startup issue on boot?
matthias_bgg has quit [Ping timeout: 480 seconds]
matthias_bgg has joined #aarch64-laptops
<Segfault[m]> <jhovold> "Segfault: have you noticed any..." <- i haven't had any more issues yet today and that's after cold booting and rebooting a number of times
<jhovold> how much time do you think you'll need to be able to say that issue is gone?
<jhovold> you said every 2/3 boots at one point so I was hoping we had a somewhat reliable reproducer in your setup
<Segfault[m]> i'd maybe give it another day to be sure but otherwise it seems fixed
<jhovold> ok, thanks, let me know how it goes
<adamcstephens> i just tried setting regulator_ignore_unused, and it does indeed stop the display from blanking
<adamcstephens> jhovold: assuming there are no downsides, it may be worth adding that to your recommend kernel args
<jhovold> adamcstephens: there could be downsides, so i don't want to recommend it generally
<jhovold> but I could possibly add a comment for people doing FDE
<jhovold> or you can just include the display drivers in the initramfs as mentioned in johan_defconfig
<jhovold> (the commit message of johan_defconfig)
Libre___ has quit [Ping timeout: 480 seconds]
<adamcstephens> what could be the downsides?
<adamcstephens> i need to dig deeper into the nixos initrd generation to understand how to add extra firmware. if i can figure that out i could move msm loading to initrd
matthias_bgg has quit [Quit: Leaving]
<jhovold> adamcstephens: wasted power
rz_ has quit [Ping timeout: 480 seconds]
rz has joined #aarch64-laptops
<adamcstephens> good to know
<jhovold> should be fine with the current setup, but could change if we start describing more regultors later, etc
<adamcstephens> yeah, i'll use it as a workaround for now for FDE purposes, but will plan on finding the right incantation for initrd firmware
Libre___ has joined #aarch64-laptops
<martiert> adamcstephens: to get the gpu firmware into the initrd on nixos, the easiest was to patch the kernel. It is missing an entry for the firmware it loads for the x13s. https://github.com/martiert/nixos-module/tree/main/machines/sc8280xp/kernel/add_firmware.patch
<martiert> this is using steevs kernel, which probably is similar with the GPU driver to jhovolds kernel.
<martiert> nixos just queries the modules you add to initrd to decide what firmware to pull inn
<robclark> we do need some better upstream soln for figuring out _which_ fw needs to be in initrd, adding every possible device's signed zap fw isn't going to be scaleable
<jglathe_sdbox2> yep ^^
<robclark> maybe the kernel could track fw loaded per device and expose that to dracut somehow
Lucanis has quit [Ping timeout: 480 seconds]
Lucanis has joined #aarch64-laptops
todi has joined #aarch64-laptops
<jglathe__> robclark: firmware_class:fw_log_firmware_info: perhaps
<jenneron[m]> robclark:martiert: i started solving this problem in pmOS another way: loading firmware from NHLOS partition on the device on initramfs stage https://gitlab.com/postmarketOS/msm-firmware-loader/-/merge_requests/9
<jenneron[m]> some devices don't have this partition, but maybe firmware still can be extracted in runtime e.g. form EFI capsule?
<jenneron[m]> from*
<adamcstephens> martiert: i looked into it again today and what i realized is it's the non linux-firmware video acceleration firmware that isn't being copied into the initrd
<adamcstephens> afaik i know, the regular gpu firmware works just fine
echanude has quit [Quit: WeeChat 4.2.1]
<adamcstephens> here's my current config: https://codeberg.org/adamcstephens/nixos-x13s
mcbridematt has joined #aarch64-laptops
echanude has joined #aarch64-laptops
<Jasper[m]> Anyone have a reference on how to correctly dump ACPI tables of these WoS laptops and disassemble them?
<Jasper[m]> I have a Samsung Galaxy Book2 Go (sc7280) I can try work on
<Jasper[m]> * can try to work on
<jenneron[m]> Jasper: i think you can dump it with ssdttime
<jenneron[m]> and decompile with iasl
<jenneron[m]> also good luck with writing a driver for samsung EC
<Jasper[m]> jenneron[m]: Thanks!
<Jasper[m]> jenneron[m]: I think someone began working on it for the first book go rightM
<Jasper[m]> s/rightM/right?/
<jenneron[m]> i haven't heard of it
<jenneron[m]> so i doubt
<jenneron[m]> that EC is quite cursed, it uses something like 5 i2c buses
<jenneron[m]> but if we want just battery/charging without fixed current it should not be too hard besides reverse-engineering part
<jenneron[m]> *with fixed current
<Jasper[m]> Oh god that sounds horrible
<Jasper[m]> Time to get my skills up them
<Jasper[m]> n
<jenneron[m]> there is a chance we can avoid reverse-engineering part
<jenneron[m]> start buying random samsung x86 laptops, hope that it uses similar EC and that it is defined in ACPI, then dump ACPI tables and use it as reference
<jenneron[m]> i think it should be defined in ACPI on x86 laptops if any of those use similar EC because those laptops should work on linux, so they don't require a specific driver
<Jasper[m]> The battery device in Windows did say it was ACPI compatible or compliant or smth
<jenneron[m]> you can start from getting core i5 version of samsung galaxy book s
<Jasper[m]> "ACPI-Compliant Control Method Battery"
<jenneron[m]> Jasper[m]: huh? send your DSDT table
<jenneron[m]> there is a chance your device is different
<Jasper[m]> Well it is the book2 go 😄
<jenneron[m]> Jasper: galaxy book go, galaxy book s, galaxy book go 5g, galaxy book 2 use that EC
<Jasper[m]> <jenneron[m]> "huh? send your DSDT table" <- ^
<jenneron[m]> decompile it..
<jenneron[m]> and publish
<Jasper[m]> Oh my bad
<konradybcio> that's more like an i-polynomial-c at this point!
<Jasper[m]> Hah if I try to use the other tables as an external object resolution file they don't get recognized as an aml table
<konradybcio> iasl -d foo?
<Jasper[m]> konradybcio: iasl -e *.aml -d dsdt.aml
<Jasper[m]> Doing it without the e flag tells me that there's 4 unresolved external control methods
<Jasper[m]> Ah wait, no wonder
<Jasper[m]> it didn't dump the ssdt
<Jasper[m]> Does that make sense?
<Jasper[m]> (with the unresolved external control methods I mentioned, not sure how to solve that)
<jenneron[m]> Jasper: push it to github or somewhere
<jenneron[m]> Jasper: huuh, that seems really dope
<jenneron[m]> i looked into it only for 20 seconds, but it seems to use same/similar EC, but describing stuff in ACPI
<jenneron[m]> yeah it looks promising
<Jasper[m]> jenneron[m]: Will do tomorrow
<Jasper[m]> jenneron[m]: Use for ACPI on ARM64 finally found. More news at 7
<Jasper[m]> Good to hear anyways
<Jasper[m]> I'm a bios update behind so I'm installing that now
<Jasper[m]> And I'm going to figure out soon if I can dump all the drivers off windows update