01:26 <nicolas17> my troubleshooting is severely limited by my lack of understanding of what I am doing

02:08 <nicolas17> it's failing to read from 0x690100000

02:12 <nicolas17> or rather, from 0x690200000; I changed devno to 1 as a test which didn't work either

02:12 <nicolas17> the ADT says apcie.reg[0] has address 690000000 so that seems correct

02:13 <nicolas17> maybe I'm not supposed to be loading trace_wlan at startup because I need to wait for the hardware to be initialized?

02:21 <nicolas17> - I think I tested loading the script after macOS had booted and it didn't work

02:21 <nicolas17> - then I tested loading it at startup and it didn't work

02:21 <nicolas17> - then I tested changing devno to 1 instead of 2, and loading it at startup, and it didn't work

02:22 <nicolas17> - but I never tested devno=1 with running system

02:30 <nicolas17> so it *seems* to work now but I'm not actually getting any log messages

02:30 <nicolas17> only for this at the beginning: [cpu0] PT[690100000:690101000] -> WSYNC.RW WLANTracer@/arm-io/apcie/01:00.0

02:48 <nicolas17> https://github.com/AsahiLinux/docs/wiki/SW:Getting-started this makes me sad

02:51 <nicolas17> hm looks like m1n1 HV doesn't survive macOS going to sleep

04:40 <nicolas17> I'm cross-referencing logs and Linux driver and damn this is overwhelming as heck

04:53 <nicolas17> the log has all these MMIO writes to COMMAND (0x690100004), the driver defines BRCMF_PCIE_CFGREG_STATUS_CMD but doesn't actually *use* it, wth

18:27 <zzywysm> nicolas17: yes, on Apple Silicon the NVME storage is all encrypted at-rest by default. but by enabling FileVault, you add another layer of encryption with a key that is SEP-resident

18:30 <zzywysm> nicolas17: i believe these days FileVault only encrypts your user data (i.e. your Data APFS subpartition on macOS) because with the concept of full system cryptographic sealing (or whatever Apple calls it) applying FileVault encryption to your macOS system files is unnecessary