03:36 <clover[m]> here's the output from the laptop without the issue:... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/ZXWNliDiKIaDrxedWcIbKrht>)

03:36 <clover[m]> * here's the output from the laptop without the issue:

03:36 <clover[m]> [ 1015.334871] wlan0: deauthenticating from f0:2f:74:5d:73:04 by local choice (Reason: 3=DEAUTH_LEAVING)

03:36 <clover[m]> [ 1020.364644] ath11k_pci 0006:01:00.0: BAR 0: assigned [mem 0x30400000-0x305fffff 64bit]

03:36 <clover[m]> [ 1020.365484] ath11k_pci 0006:01:00.0: MSI vectors: 32

03:36 <clover[m]> [ 1020.365521] ath11k_pci 0006:01:00.0: wcn6855 hw2.1

03:36 <clover[m]> [ 1020.525826] mhi mhi0: Requested to power ON

03:36 <clover[m]> [ 1020.525844] mhi mhi0: Power on setup success

03:36 <clover[m]> [ 1020.635899] mhi mhi0: Wait for device to enter SBL or Mission mode

03:36 <clover[m]> [ 1021.274439] ath11k_pci 0006:01:00.0: chip_id 0x2 chip_family 0xb board_id 0x8c soc_id 0x400c0210

03:36 <clover[m]> [ 1021.274483] ath11k_pci 0006:01:00.0: fw_version 0x110b196e fw_build_timestamp 2022-12-22 12:54 fw_build_id WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23

03:36 <clover[m]> [ 1028.912098] wlan0: authenticate with f0:2f:74:5d:73:04

03:37 <clover[m]> [ 1029.120891] wlan0: send auth to f0:2f:74:5d:73:04 (try 1/3)

03:37 <clover[m]> [ 1029.125347] wlan0: authenticated

03:37 <clover[m]> [ 1029.127318] wlan0: associate with f0:2f:74:5d:73:04 (try 1/3)

03:37 <clover[m]> [ 1029.130198] wlan0: RX AssocResp from f0:2f:74:5d:73:04 (capab=0x1011 status=0 aid=17)

03:37 <clover[m]> [ 1029.206535] wlan0: Limiting TX power to 24 (24 - 0) dBm as advertised by f0:2f:74:5d:73:0

03:37 <clover[m]> [ 1029.146251] wlan0: associated

03:37 <clover[m]> the only difference i see with that and my modem x13s is the number after mhi (mhi0 vs mhi1) in the power on request part

03:37 <clover[m]> wlan0 is not up so that might be causing things to fail too

07:30 <Xyaon> hexdump0815: Thanks for the info, I'm currently using steev's sc8180x-next20220728+usb-mp+a680 branch and basing my dtb off the flex 5g and primus. I'm somewhat familiar with gpu firmware stuff, I did that on my c630 fine, my current concern is that the reserved memory ranges of the flex 5g/primus do not match each other, neither the ranges I got from windows.

07:33 <Xyaon> hexdump0815: I have a fork of it with my dtb + config under the same name on github, and a public gist with the memory ranges from windows

08:06 <agl7> Good Morning :-)

08:07 <Xyaon> gm :}

09:39 <DocGalaxyBlock[m]> <hexdump0815> "i think there was recently..." <- xyaon - that was me (but no real deeper linux experience)... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/SacFXaQDqOQTezPIMtgtkTYL>)

09:39 <DocGalaxyBlock[m]> xyaon:

09:43 <Xyaon> DocGalaxyBlock[m]: I assume you booted it with acpi without a dtb?

09:44 <DocGalaxyBlock[m]> Even that question is out of my knowledge.

09:44 <DocGalaxyBlock[m]> I just flashed the isos to a usb drive and booted from it

09:46 <Xyaon> Well, I got the keyboard and mouse working, but not much else yet

10:08 <Xyaon> Is there any way of getting the memory range where firmware should be loaded from windows?

10:10 <Xyaon> currently any remoteproc load fails and takes down the whole thing with it

10:11 <travmurav[m]> xyaon: what specific firmware is the problem?

10:12 <travmurav[m]> for remoteproc blobs there are two sources: each ELF has alignment, size and possibly base address if it's not relocatable, then the windows driver has .ini file with addresses for the blob loading

10:23 <Xyaon> adsp, cdsp, mpss. I shouldn't have expected it to work with the flex 5g's addresses. I'll try looking for them there, thanks!

10:25 <travmurav[m]> xyaon: generally the blobs like that should be relocatable so any address /should/ work unless it's already taken by something. Also you might want to dump the uefi memory map and see if there is some reserved area already for those so you don't reserve extra space on top of what is already blocked out by uefi

10:27 <travmurav[m]> you could probably even do dynamic address selection within a given range if there is a clear carveout

10:30 <Xyaon> travmurav: I don't get any overlap warnings, it just freezes the system. So the reserved memory ranges in the dts for rmtfs, gpu, *dsp, mpss, etc are arbitrary as long as they don't overlap?

10:31 <travmurav[m]> not sure about rmtfs but for mbn blobs they generally /should/ be arbitrary, yes

10:33 <Xyaon> unfortunatelly I do get an overlap warning when I try to set the rmtfs address to the windows one :l

10:34 <konradybcio> it's possible than other reserved regions are wrong

10:34 <konradybcio> if you get your bootloader and run strings and grep for 0x[0-9a-z]+{8,10} you'll get a map of reserved space

10:35 <konradybcio> that would be on the xbl partition or in an update package

10:38 <Xyaon> which bootloader file should I run strings on? the .efi?

10:41 <Xyaon> the warning I got was that the windows rmtfs overlaps with the xbl, in fact they were on the same address. Do you think the problem with the xbl's definition or just that windows hadles these things differently

10:43 <konradybcio> xyaon: what is your storage? ufs/emmc or nvme?

10:44 <Xyaon> nvme

10:44 <konradybcio> right that makes it harder as the bootloader lives on a spi flash

10:44 <Xyaon> ugh

10:44 <konradybcio> if you boot to efi shell, you should be able to run memmap

10:44 <Xyaon> I'll try that

10:45 <Xyaon> I already had to get this laptop repaired, because i was probing its insides

10:46 <Xyaon> I should have tried asking for the old motherboard

10:47 <Xyaon> also, I think they messed my firmware up because the gpu is reported as an adreno 680 instead of a 675

10:49 <Xyaon> Thanks for the help, I'll let you know if I find something

10:50 <konradybcio> i am not sure if qualcomm ever cared enough to rename it

10:51 <konradybcio> there are like 4 non-x 8c devices on the planet :D

10:52 <Xyaon> probably

10:52 <Xyaon> but the cpu is reported as an 8c

10:53 <Xyaon> so out of those four devices, I have the only 8c + a680 one :D

10:54 <Xyaon> well before the repair it was called a 675 in windows

10:56 <Xyaon> maybe they're just the 680s that had some fabrication issues and were clocked down etc

10:57 <konradybcio> or maybe the windows driver doesn't care

11:49 <Jasper[m]> @clover @steev updated to rc7 and rebooted. Speakers still work okay, headphones are still loud

11:49 <Jasper[m]> Didn't have trouble with it crashing on boot for a bit before I updated, that issue seems to be back

11:50 <Jasper[m]> persistent journalling didn't save that crash it seeks

11:50 <Jasper[m]> s/seeks/seems/

12:34 <Xyaon> konradybcio: I have looked trough the .mbn files, I think the memory ranges are fine for now. The current problem with remoteproc is that it restarts the usb system and the pendrive that I'm using to boot from gets reassigned from sda to sdb, and it dies.

12:34 <konradybcio> that's a known issue :(

12:34 <Xyaon> The nvme is not working yet, so I can't boot from there

12:35 <Xyaon> Can I force remotproc to run before the root switch?

12:39 <konradybcio> doubt

12:39 <konradybcio> i'd guess you're missing some sort of a gpio regulator for the nvme

12:40 <konradybcio> check the gpios under pcieX in the dsdt

12:52 <jenneron[m]> yes you can

12:52 <jenneron[m]> https://gitlab.com/postmarketOS/pmaports/-/blob/master/device/testing/firmware-samsung-w767/APKBUILD#L44-48

12:55 <Xyaon> How could I do that in a "regular" iniramfs?

12:55 <jenneron[m]> i don't know what you mean, if you mean that you have your own initramfs based on busybox or something then just place a file there

12:56 <jenneron[m]> it is like this for any initramfs

12:56 <jenneron[m]> but keep on mind that you also need kernel modules in initramfs required for remoteproc

12:58 <Xyaon> You mean the firmware files? I already have them in the image.

12:58 <jenneron[m]> firmware and modules

13:14 <Xyaon> Thank you, that worked.

13:21 <Xyaon> konradybcio: I can't seem to find anything pci/gpio related in my dsdt :l

13:21 <Xyaon> Here are all the firmware files I was able to find: https://drive.google.com/drive/folders/1YYaStyBvs4SXlx0ZPTBS-1B4vQZgxny_?usp=sharing

14:25 <Xyaon> the remoteproc for the mpss keeps crashing

17:04 <steev> Jasper[m]: did you try lowering the volume itself once the headphones are in? i have the temp hack patch in there, but people do complain that it causes other noise with it in

17:06 <steev> xyaon: that is a pretty old -next branch, and 8180x support is in the kernel now i believe (very basic) but i've been ridiculously busy with work (but hey, 2023.3 is out today so woo) so haven't had time to circle back to 8180x things

17:06 <steev> i *think* vkoul is the one doing 8180x things?

17:18 <Jasper[m]> <steev> "Jasper: did you try lowering the..." <- "the volume itself" being a channel in alsamixer or using something like pavucontrol?

17:18 <steev> i'd say use pavucontrol

17:18 <Jasper[m]> Because I did the latter, the volume itself becomes bearable around 10% but with a lot of noise as you said

17:18 <steev> (personally i just hit the volume down buttons on the laptop)

17:18 <steev> try dropping the temp hack patch for headphone volume lowering

17:31 <Xyaon> steev: Oh, I didn't know it was in mainline. I think some issues I encountered got fixed in newer versions. thanks

17:42 <steev> it'll only be torvalds tree, or next

17:43 <steev> Jasper[m]: hm, actually, here, i don't even have headphone detection it seems :/

17:44 <steev> neither my earpods nor some sony headphones i found are detecting, this is annoying

17:44 <Jasper[m]> steev: That did work for me

17:45 <Jasper[m]> It's still that the amplification is weird

17:45 <steev> try backing the patch i mentioned out

17:45 <Jasper[m]> currently don't have the setup for that, otherwise I would

17:45 <Jasper[m]> I might look at it later if I remember it

17:57 <steev> relatable

23:08 <clover[m]> Anyone interested in rhino linux distro? Seems kinda cool

23:08 <clover[m]> They have generic arm images