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
<craftyguy> Remove "quiet" and maybe you'll get some useful info from the kernel
<craftyguy> if it still hangs on a black screen, then add the earlyprintk option, and/or others to try and get the kernel to print _something_ before it hangs, to give you some hint about where it gets stuck
<agl> clover[m]: Are you online?
laine has joined #aarch64-laptops
<steev> FarchordSteveCossette[m]: might try adding arm64.nopauth ?
<FarchordSteveCossette[m]> steev: I'll try all that in a second. Mind you I think it's possible the kernel wasn't built (Maybe) with the modules required. But I'll try those
<steev> getting more output is always good as a first step :)
<FarchordSteveCossette[m]> <craftyguy> "if it still hangs on a black..." <- With quiet off it does show some text but then just goes back blank ill try other stuff
<FarchordSteveCossette[m]> Hard to read ill give you this
<strongtz[m]> Jos Dehaes: I think you can manually copy your files to the rootfs dir, and do a `--repack` afterwards
<strongtz[m]> Farchord (Steve Cossette): could you try adding `clk_ignore_unused pd_ignore_unused`?
<FarchordSteveCossette[m]> strongtz[m]: Well, went farther this time hold on
alpernebbi has quit [Ping timeout: 480 seconds]
<FarchordSteveCossette[m]> Stupid plymouth
<FarchordSteveCossette[m]> Lemme edit the boot args on the drive and disable plymouth one sec
alpernebbi has joined #aarch64-laptops
<strongtz[m]> Farchord (Steve Cossette) hm, what about adding `regulator_ignore_unused` as well?
<strongtz[m]> Is it doing a reset after that?
<FarchordSteveCossette[m]> Yes
<FarchordSteveCossette[m]> Aiite 63rd time’s the charm
<FarchordSteveCossette[m]> Why is element showing the video sideways
<strongtz[m]> Are you building the kernel yourself?
<FarchordSteveCossette[m]> strongtz[m]: No this is the stock fedora kernel
<FarchordSteveCossette[m]> I dont really know how to build my own lol
<FarchordSteveCossette[m]> But ill go to sleep thanks for your help!
<strongtz[m]> np, I did make some hacks during testing, for example
<strongtz[m]> not sure if those two sync_state hacks actually did something
<FarchordSteveCossette[m]> But you gotta admit this aint bad
<strongtz[m]> yeah :p
<FarchordSteveCossette[m]> Ill play with it more tomorrow
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
phire_ has joined #aarch64-laptops
phire is now known as Guest828
phire_ is now known as phire
Guest828 has quit [Ping timeout: 480 seconds]
<colemickens> are there kernel modules that are important to have in initrd specifically?
<colemickens> and/or anything else an image would need, to test, besides abelvesa's kernel, appropriate dtb, mesa main with x1 commit, ... and a pinch of luck
<HdkR> I found out yesterday that the bitcoin project uses rndrrs if it is available on aarch64 to fill its entropy pool. It spins in a loop until its pool is filled.
<HdkR> This means on Oryon it will hang at startup because of the bugged rndrrs :D
<steev> colemickens: ^^ johan has that list of modules that should be in the initrd
<steev> that does assume his kernel config being used, but still
<steev> i'd assume once gpu and such are done, you'll have similar gpucc and dispcc modules, but with x1e
laine has quit [Ping timeout: 480 seconds]
<colemickens> I think the only one from that list not found was "Module pcie_qcom"
<colemickens> but nvme, phy_qcom_qmp_pcie, phy_qcom_qmp_ufs, ufs_qcom were so /shrug
<abby> to have pcie_qcom as a module you need a patch from johan's branch
<colemickens> hm, I'm not sure if I want it. I like just using abelvesas branch
<abby> it's fine without it, it just means you can only do CONFIG_PCIE_QCOM=y
<colemickens> okay, thanks!
<abby> and thus it's always in the initramfs because it's in the main kernel image
laine has joined #aarch64-laptops
<steev> right :) the only thing to do would be check if there are the 8280 related modules but with an x1e of some sort, so like, dispcc_x1e08000 or whatever
<steev> but they may not exist yet
<steev> i'm guessing as i don't have an x1e
<colemickens> gpucc-x1e80100.ko.xz
<colemickens> dispcc-x1e80100.ko.xz
<colemickens> tcsrcc-x1e80100.ko.xz ?
<abby> probably those yeah
<steev> i have no idea what tcsrcc is, but it might not hurt
<steev> ah that might be usb related
<steev> actually that might be pcie and usb
<JosDehaes[m]> <strongtz[m]> "Jos Dehaes: I think you can..." <- That would probably work, but it's a manual step. Would be nice if it could be done declaratively
<JosDehaes[m]> I'll see if I can add this feature when I have time
gwolf has quit [Quit: WeeChat 4.3.1]
gwolf has joined #aarch64-laptops
laine has quit [Ping timeout: 480 seconds]
Kelsar has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
Kelsar has joined #aarch64-laptops
<sera[m]> I needed to add that earlier, if you want to just get it running you can use this diff https://pastebin.com/QDKtKGdu - use link: instead of content: to specify the path. also allows packages to be files
<sera[m]> <FarchordSteveCossette[m]> "video_8bca1e8.mp4" <- it looks like journal service started so you might be able to get that off the boot drive for more useful info?
hightower4 has joined #aarch64-laptops
hightower3 has quit [Ping timeout: 480 seconds]
<JensGlathe[m]> <FarchordSteveCossette[m]> "video_8bca1e8.mp4" <- Hmm not here, right orientation
<FarchordSteveCossette[m]> <sera[m]> "it looks like journal service..." <- https://paste.centos.org/view/35c308b7
<FarchordSteveCossette[m]> The GPU driver seems to die
smpl has joined #aarch64-laptops
<strongtz[m]> Jos Dehaes: .sera The builder has been updated :)
<robclark> FarchordSteveCossette[m]: the generic_edp_panel_probe() WARN_ON() is safe to ignore for now.. if it is an OLED panel chances are that something like https://www.spinics.net/lists/kernel/msg5294937.html will work
<FarchordSteveCossette[m]> robclark: So then I wonder why I'm hard rebooting
<robclark> i had that problem early on... it was resolved by using something closer to the x1e defconfig but not sure _what_ change fixed it
<FarchordSteveCossette[m]> yeah I think ill need to build my own kernel.... sigh
<FarchordSteveCossette[m]> I don't have an aarch64 machine so it'll be a long build lol
<agl> FarchordSteveCossette[m]: Good Luck.
<FarchordSteveCossette[m]> agl: thanks lol
<clover[m]> <agl> "clover: Are you online?" <- what's up?
mcbridematt has quit [Read error: Connection reset by peer]
Mathew has joined #aarch64-laptops
<agl> clover[m]: The graphical system starts very rarely under EndeavourOS. Most of the time it does not start. I don't know what the problem could be.
<clover[m]> what do the logs from your graphical system say?
<clover[m]> i don't have those issues using gnome + wayland
<agl> When it starts I see in dmesg that adrena is initialized after msm ... when it not starts the adrean is tried to initialize bevor msm.
<agl> clover[m]: I will start EndeavourOS ...
<robclark> FarchordSteveCossette[m]: fwiw here is .config that I am currently using: https://paste.centos.org/view/2b4952ee
<FarchordSteveCossette[m]> robclark: Sweet... I'll look into that thanks!
<robclark> also potentially useful:
<robclark> and kernel cmdline: dtb=/x1e80100-lenovo-yoga-slim7x.dtb root=/dev/nvme0n1p3 ro rootflags=subvol=root console=tty0 clk_ignore_unused pd_ignore_unused arm64.nopauth efi=novamap rhgb
<agl> clover[m]: Which Kernel-parameters have you under kernel 6.10?
<agl> clover[m]: I have started EndeavourOS and I'am loged in per ssh.
<agl> *logged
<agl> clover[m]: /etc/default/grub --> GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 efi=noruntime clk_ignore_unused pd_ignore_unused arm64.nopauth"
<clover[m]> looks good to me
<clover[m]> you might need GRUB_EARLY_INITRD_LINUX_CUSTOM=initramfs-linux-x13s.img
<agl> I have a look to /var/log/Xorg.log
alpernebbi has quit [Ping timeout: 480 seconds]
<clover[m]> add that line and then regenerate your grub config
<agl> yes I have the GRUB_EARLY_INITRD_LINUX_CUSTOM=initramfs-linux-x13s.img
<robclark> FarchordSteveCossette[m]: updated conflig to change remoteproc stuff into modules (because adsp/cdsp fw is not in initrd): https://paste.centos.org/view/d4b1d2e4
<agl> clover[m]: I have this generated bevor the boot. It works.
<agl> clover[m]: the xorg.0.log is from 14:01 o'clock and that was the time where the grafical system starts and ends normal.
<agl> clover[m]: in the dmesg now are following lines (grafical system not started):
<agl> [ 4.851573] sd 1:0:0:0: [sdb] Attached SCSI disk
<agl> [ 11.976312] EXT4-fs (nvme0n1p5): mounting ext2 file system using the ext4 subsystem
<agl> [ 12.004106] arm-smmu 3da0000.iommu: deferred probe timeout, ignoring dependency
<agl> [ 11.978065] EXT4-fs (nvme0n1p5): mounted filesystem 8a7d7bf1-9aa7-4ab6-9c94-388d3b599a7a r/w without journal. Quota mode: none.
<agl> [ 12.004112] arm-smmu 3da0000.iommu: probe with driver arm-smmu failed with error -110
<agl> [ 12.004228] adreno 3d00000.gpu: deferred probe timeout, ignoring dependency
<agl> [ 12.004230] adreno 3d00000.gpu: iommu configuration for device failed with -ETIMEDOUT
<agl> [ 12.004334] msm-mdss ae00000.display-subsystem: deferred probe timeout, ignoring dependency
<agl> [ 12.004337] msm-mdss ae00000.display-subsystem: probe with driver msm-mdss failed with error -110
<agl> clover[m]: It seems the arm-smmu can not initialized.
alpernebbi has joined #aarch64-laptops
<agl> clover[m]: I see there is a EXT4-fs-Mount without journal .... I start Debian/testing and make a fsck /dev/nvme0n1p5 ....
<robclark> agl: cat /sys/kernel/debug/devices_deferred
<clover[m]> i've noticed that sometimes an fsck is necessary after updating a kernel, or just randomly. but i think either grub or an initrd process should do that automatically
<agl> clover[m] & robclark: After a fsck, where at Boot time is NOT made an fsck, the grafical system starts.
<agl> [root@EOS-x13s ~]# cat /sys/kernel/debug/devices_deferred
<agl> [root@EOS-x13s ~]#
<robclark> hmm, ok.. I guess it had some problem loading modules before?
<agl> it seems it's a timing problem
<agl> robclark: Now the grafical system have been started now.
<agl> clover[m]: I start the x13s once more ... bevor i Update 6 packages
<agl> clover[m] & robclark: I have now set the mount counter of the ext4 fs to 3. All 3 starts after that, the grafical system starts. At the 4 start then with an fsck the grafical system starts NOT!
<robclark> check devices_deferred when it doesn't start?
<robclark> I guess somehow the timing of when the fs is avail makes something not load, but idk why
<agl> It seems that the msm Module which is in the initramfs-linux-x13s runs to a timeout because there is firstly do a fsck.
<robclark> compare lsmod in good/bad cases
<agl> ok
<robclark> not really sure what the connection to arm-smmu is
<agl> One Moment
<robclark> note that I have CONFIG_ARM_SMMU=y
<agl> I mean that is set by clover's config for the kernel 6.10
<robclark> to =y or =m?
<agl> robclark: One Moment I do firstly the lsmod_good and lsmod_bad ...
<agl> diff lsmod_good lsmod_bad -->
<agl> 109,110c107,108
<agl> < msm 659456 23
<agl> < phy_qcom_edp 16384 1
<agl> ---
<agl> > phy_qcom_edp 16384 0
<agl> > msm 659456 0
<agl> 118c116
<agl> < phy_qcom_qmp_combo 49152 10
<agl> ---
<agl> > phy_qcom_qmp_combo 49152 8
<agl> 137c135
<agl> < drm 425984 16 gpu_sched,i2c_hid,drm_kms_helper,msm,drm_exec,panel_edp,aux_bridge,drm_display_helper,aux_hpd_bridge
<agl> ---
<agl> > drm 425984 9 gpu_sched,i2c_hid,drm_kms_helper,msm,drm_exec,panel_edp,aux_bridge,drm_display_helper,aux_hpd_bridge
<agl> msm has in good 23 modules. In bad 0!
<agl> robclark: Now i look for CONFIG_ARM_SMMU=y
<agl> robclark: CONFIG_ARM_SMMU is set on yes in the config-file of the kernel 6.10
<agl> s/on/to/
<agl> of clover[m]
<robclark> hmm, ok
<agl> It seams msm which is in the initrd-linux-x13s to load/start it at boot time waits for other modules where after a fsck the timeout is over. Is it possible to set an bigger timeout for the msm-module?
<agl> s/an/a/
<robclark> I'm not aware of a timeout.. the driver loader code (not the driver itself) will re-probe drivers on the deferred list whenever some other module successfully probes, to resolve dependencies
<robclark> devices_deferrred still empty in the bad case?
<agl> One MOment ...
<robclark> it could be some other driver fails to probe due to lack of fw, I guess
<agl> [root@EOS-x13s ~]# cat /sys/kernel/debug/devices_deferred
<agl> [root@EOS-x13s ~]#
<agl> clover[m] & robclark : The Problem is the fsck when the mount count is reached. I set the mount counter to 5 and when the fsck is running I have to restart the EndeavourOS.
<agl> 5 times it runns, one not, 5 times it runns ....
<agl> s/runns/runs/g
<agl> clover[m]: I have found the problem: It's the fsck where the msm module (in the initrd-linux-x13s) runs on an timeout because it can not load further modules.
<agl> s/an/a/
<agl> clover[m]: Or there can not load some firmware files while the fsck is running and the file system is not mounted in this time.
<clover[m]> feel free to make a PR
<agl> clover[m]: PR?
<steev> are you really corrupting your filesystem so often?
<Jasper[m]> steev: A while back I ran alarm aswell, and it wasn't fun
<agl> steev: No it is quite stable by now. In the past I often had the problem that FS errors occurred.
<agl> steev: When I restarted the FS was corrupt
<agl> steev: Do you know what clover[m] means with PR?
<steev> i do not. i'm not sure if this is a userland or kernel issue, but having to fsck shouldn't cause the display not to load so maybe it's a kernel issue, i've just never seen it here
<JensGlathe[m]> agl: could be related to booting from USB type-c. I just had a similar thing with a new image from a fast type-c SSD enclosure, and first (unswapped) boot went into a wall. Added rootdelay=20 rootwait, seems to mitigate it. First boot is without firmwares available, seems to favor this type of error
<pstef> I bet PR is Problem Report, aka Bug Report
<abby> pull request
<pstef> I hope not
<abby> seeing as clover's ALARM stuff is on github...
laine has joined #aarch64-laptops
<clover[m]> Pull request
<agl> clover[m]: with "rootdelay=40 rootwait" works fine!
<agl> Oh Pull request ... I'am not firm in git.
<pstef> we used to call those patches...
<abby> good for you
<abby> we still call them patches sometimes
<anarsoul[m]> out of curiosity, how long does the battery last on X Elite-based laptops?
<anarsoul[m]> I'm trying to find an argument for myself to buy another expensive toy :)
anarsoul has joined #aarch64-laptops
<steev> longer than a pinebook pro :P
<anarsoul[m]> yeah, but pinebook pro is just $200
<steev> the battery isn't the reason for the cheapness tho, it's pretty dang good
<steev> but i know you know that
<pstef> the benchmarks I saw shared here weren't too convincing compared to x13s, but perhaps I read them wrong or maybe they're too synthetic
<steev> the power management still needs a bit of work on x1e/8280xp
<anarsoul[m]> I saw some power consumption benchmarks that say asus consumes ~8W when idle. That's for Windows
<HdkR> https://docs.google.com/spreadsheets/d/1AlScIvZZLGwER5LSE1Y_smQJdVtTVxGxRPF-HAJGbuA/edit?gid=321706246#gid=321706246 Some bytemark benchmarking I did yesterday with a comparison to X13s below.
<HdkR> X1E mostly wins but it loses in some cases
<HdkR> Seems like bytemark hits some edge case in the CPU that ends up in rough shape
<HdkR> 35% win for averaging all the single core results isn't terrible
<HdkR> multicore it'll obviously beat X13s. 50% more cores and all Oryon-1 instead of X1C+X78C :)
<pstef> how do these laptops not overheat? The x13s can get surprisingly hot
<anarsoul> pstef: active cooling?
<HdkR> Active cooling helps
<steev> yeah, the x1e has active cooling :(
<HdkR> Yoga 7x even has two fans
<pstef> that may save them, but at the same time passive cooling is what I really liked about my x13s
<JosDehaes[m]> <strongtz[m]> "Jos Dehaes: .sera The builder..." <- Thx, it works great, however, I copy a custom initrd, but after all defined steps, it regerenates the initrd with `mkinitcpio`. Is this step hardcoded? I don't see it in my config
<JosDehaes[m]> * my config. This then overwrites my custom initrd of course
<JosDehaes[m]> ah there's a stage parameter
<JosDehaes[m]> * ah there's a stage parameter, yes that works!
<robclark> anarsoul[m]: re: battery life, I think not as good as windows yet (still too many things getting left on by linux, but that situation will improve).. compared to other laptops the windows battery life seems good despite many of these things having high resolution, high refresh, oled panels.. so the potential is defn there. (But we probably need compositor to be clever about switching down to lower refresh rates, and
<robclark> things like that)
<anarsoul[m]> robclark: so how many hours?
<robclark> I've not really tested yet.. and at this stage I'm rebooting constantly ;-)
Lucanis has quit [Ping timeout: 480 seconds]
Lucanis has joined #aarch64-laptops
<frozen_cheese[m]> finally have my yoga 7x booting into a functional arch linux.... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/VMLrTmxIZKyDZimASmOvLjxG>)
<HdkR> To me it seems like ath12k is missing some firmware file for the wifi
<HdkR> kernel log complains about some missing files before ath12k messages vanish
<frozen_cheese[m]> yeah, I was afraid of that. I was looking around and I found some stuff online about other ath12k devices missing firmware :(. was hoping that was not the case
<robclark> HdkR: for yoga 7x wifi you want `arm64: dts: qcom: x1e80100-yoga: add wifi calibration variant`
<HdkR> Ah, fancy
<JosDehaes[m]> frozen_cheese: you need the ath12k firmware from https://github.com/Seraphin-/linux-firmware-x1e80100-lenovo-yoga-slim7x
<robclark> you can either patch the fw or take the dts patch for wifi cal variant, afaiu
<HdkR> Looks like soft-irq still smashes a CPU core with 5gbit ethernet :D
<HdkR> At least the cores are fast enough to achieve higher speeds now
<frozen_cheese[m]> <JosDehaes[m]> "frozen_cheese: you need the ath1..." <- sweeeeet! tyvm!!
<steev> bryanodonoghue: do we *need* dma heaps in order to use the cam?