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
iivanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
bluerise_ has joined #aarch64-laptops
bluerise has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
<TSIN[m]>
<TSIN[m]> "Can vivobook s15 support boot..." <- On vivobook s15, the key is 'Esc'...
iivanov has quit [Ping timeout: 480 seconds]
<kuruczgy[m]>
<FarchordSteveCossette[m]> "https://github.com/jhovold/linux..."; <- Thanks. Unfortunately I get the exact same crash with this kernel :/ In the meantime though I discovered colemickens' nixos repo, there are some comments there about disabling udev's 80-drivers.rules, so next I will look into that I think.
<FarchordSteveCossette[m]>
kuruczgy[m]: Actually don't do that. There's another module to blacklist
<FarchordSteveCossette[m]>
it's a qcom module, maybe nirik remembers offhand.
<FarchordSteveCossette[m]>
Once you blacklist that it just boots
<FarchordSteveCossette[m]>
oh yeah qcom_edac
<FarchordSteveCossette[m]>
I'm 95% sure it's that one
<nirik>
yes, those two
<kuruczgy[m]>
I have already have qcom_edac and qcom_q6v5_pas blacklisted, so if there is a third one it's different maybe?
<FarchordSteveCossette[m]>
Not to us anyway
<kuruczgy[m]>
The module_blacklist=qcom_edac,qcom_q6v5_pas kernel param should do the job, right? I have that right now, so in that case it seems there is some other weirdness with my setup...
<FarchordSteveCossette[m]>
kuruczgy[m]: No the crash occurs in userspace, that's initrd only no?
<FarchordSteveCossette[m]>
gotta add it to /etc/modules.d if memory serves?
<kuruczgy[m]>
Ok I will try that, thanks, will get back later. (Maybe tomorrow it's getting kinda late.)
<nirik>
in fedora land at least I think it's modprobe.blacklist= but module_blacklist might work in some other contexts, dunno
<FarchordSteveCossette[m]>
nirik: yeah i just think that the module_blacklist in the kernel cmdline only applies to initrd
<FarchordSteveCossette[m]>
I might be wrong on that.
iivanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
<robclark>
qcom_edac is defn the one to disable to avoid needing the udev rules hack.. I'm fuzzy on all the different ways to blacklist a modules, but disabling it in kernel config (if you are building your own kernel) or just removing the .ko works
<JosDehaes[m]>
my requirement is to be as fast as possible (for compiling big rust projects), the M4 max will be the fastest chip in the market by a big margin when it comes out in a few months
<TSIN[m]>
I'm trying to convince them to make smaller x elite machine..
<JosDehaes[m]>
and I find that I mind macOS less and less
<JosDehaes[m]>
even though I've been using linux almost exclusively for the past almost 30 years
martiert has quit [Quit: WeeChat 4.3.5]
martiert has joined #aarch64-laptops
srinik has quit [Ping timeout: 480 seconds]
srinik has joined #aarch64-laptops
<Molyuu[m]>
Anyone can help about my DSI panel driver? I've checked my current driver it does displays something (like noise) when I disable DSC. When I run dmesg, the whole screen is filled with garbage, and then I run clear, the screen cleans and the whole screen comes white. I found that the DSC is enabled in ACPI Panel Config, but after I enable it, kernel return dsi_error_worker: status=4, and about 1/8 of the screen displaying
<Molyuu[m]>
garbage, the reset of screen is displaying color lines(When I run dmesg and clear, there is indeed a noticeable change in the garbage that appears on the screen.). I write the driver based on Panel Config from DSDT.
<mlau>
JosDehaes: I do have the zap shader, I think it reboots because no init is available
<JensGlathe[m]>
in this room there was talk that qcom_edac.ko is responsible for the reboot
<mlau>
I saw that, and removed it from the build
<JosDehaes[m]>
you will need hack: arm64: qcom: x1e80100: fix HID interrupts if you want keyboard/touchpad
<JosDehaes[m]>
(once it boots)
<mlau>
thanks!
<JensGlathe[m]>
bsod update: pure defconfig works, and now mine apparrently too. For whatever reason the one big change is DRM=m (was y before), and DMA_RESTRICTED_POOL=y (was not defined before).
altacus__ has quit [Remote host closed the connection]
<mlau>
success: I ca now boot straight to a working shell with working keyboard
srinik has quit [Remote host closed the connection]
srinik has joined #aarch64-laptops
iivanov has quit [Quit: Leaving...]
fparent has quit [Ping timeout: 480 seconds]
fparent has joined #aarch64-laptops
agl has quit [Remote host closed the connection]
agl has joined #aarch64-laptops
<steev>
nice
Caterpillar has joined #aarch64-laptops
cyrinux has quit []
cyrinux has joined #aarch64-laptops
srinik has quit [Ping timeout: 480 seconds]
<craftyguy>
for those with an x13s running a recent linux kernel (6.10+), what is your favorite usb-c dock?
<craftyguy>
I've tried a few, they all kinda have their own problems with this system :(
<mlau>
JosDehaes[m]: did you get ath12k working? I took your firmware file, the driver loads, but bringing it up fails with wmi command timeout
<JosDehaes[m]>
yes, works perfectly
<mlau>
hm
<JosDehaes[m]>
did you take all the ath12k files?
<mlau>
yes, firmware is loaded, iwd shows available bands
<mlau>
but bringing it up fails with a internal command timeout
<JosDehaes[m]>
no idea sorry
<mlau>
which kernel do you use?
<JosDehaes[m]>
I did not really have a problem with wifi
<JosDehaes[m]>
I'm using jhovold's rc1 or 6.11 rc3 with some patches, but nothing wifi related
<mlau>
hm me too
<mlau>
does bluetooth work?
<JosDehaes[m]>
no
<mlau>
oh BT is H4 UART protocol
<mlau>
usb is also unusable
<JosDehaes[m]>
also not an issue here
<kuruczgy[m]>
<FarchordSteveCossette[m]> "gotta add it to /etc/modules.d..." <- Tried, no such luck. On the other hand if I disable `systemd-udevd` it boots, so it must still be some other module that udev tries to insert.