ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | Non-development talk: #asahi | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
cylm has joined #asahi-dev
chadmed_ has quit [Remote host closed the connection]
hertz has joined #asahi-dev
bps2 has quit [Ping timeout: 480 seconds]
hertz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
seeeath has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
seeeath has joined #asahi-dev
<marcan>
j`ey: I do pull via github sometimes, if the stars line up and there wasn't a rebase along the way
DragoonAethis has quit [Quit: hej-hej!]
DragoonAethis has joined #asahi-dev
derzahl has quit [Remote host closed the connection]
<chadmed>
would one of you be able to check this for misinformation at some point? no rush
<amarioguy>
chadmed: doing so right now
<chadmed>
thanks!
<amarioguy>
i always love reading about the system so it's a good refresher for me in either event
<amarioguy>
it really is awesome
<amarioguy>
just going to dump insights as i read them btw
<amarioguy>
easier for me
<chadmed>
go wild :D
<nicolas17>
"C = (A ∪ B)" seems unnecessary :P
<amarioguy>
> The kernelcache is paired to one - and only one - OS snapshot. You cannot drop in a kernelcache from Filesystem A and boot Filesystem B with it - not the kernelcache that's paired to the snapshot (it *is* paired to the apticket which includes the snapshot hash but that's distinct and part of standard img4 protections)
<amarioguy>
during ramdisk restore
<chadmed>
yeah i was just having some fun with markdown there
<amarioguy>
the restore daemon will "seal" the volume to the root hash
<amarioguy>
so for all intents and purposes yes it is paired but you can still technically run a 12.4 kc on a 12.3 sealed volume and have it work
<chadmed>
in Full Security mode?
<amarioguy>
not full
<amarioguy>
just clarifying how the whole "sealing" business works here
<chadmed>
right got it
<chadmed>
i might clarify that just for accuracy then
<nicolas17>
"On Apple Silicon machines, the SEP generates a Volume Encryption Key and xART for every APFS volume." what is a xART?
<amarioguy>
nicolas17: keybags
<amarioguy>
key/value store where encrypted at rest user data encryption keys are
<amarioguy>
(also called gigalocker)
<nicolas17>
yes but it's not defined before that sentence :)
<amarioguy>
ah
<chadmed>
"The xART is a key which prevents replay attacks from capturing the VEK."
<chadmed>
sufficient?
<chadmed>
i dont want it to get too complex, it is a crash course after all
<chadmed>
the goal here is to provide enough info for a user to not need to ask "will apple ban asahi"
<nicolas17>
yeah that's enough
<amarioguy>
yea fair
<amarioguy>
i would prefer "keybag" but that's apple specific terms so yea you can basically say that
<amarioguy>
or like "key storage" or smth
<amarioguy>
but that sentence works
<nicolas17>
like, VEK is not *explained* either but you do expand the acronym the first time, and I can guess what a "Volume Encryption Key" is for, so that's enough
<nicolas17>
but for xART there was nothing :)
<amarioguy>
true
<chadmed>
the xARTS is the keybag though right or do i have that wrong
<amarioguy>
yes xart == keybag
<nicolas17>
does ART mean Anti Replay Token?
<amarioguy>
nicolas17: as far as i've been able to discern yep
<chadmed>
yeah something like that Xtended Anti Replay Token
* nicolas17
collects codenames
<marcan>
was it extended or external?
<tpw_rules>
so there is no way to sneak out the VEK/xART before someone has enabled filevault
<tpw_rules>
or change your filevault password
<chadmed>
the VEK is stored in the SEP afaik
<chadmed>
so unless you break sepOS no
<marcan>
AIUI the keys are transferred through a back channel from SEP into ANS directly
<marcan>
so the AP never sees them, ever
<tpw_rules>
that's the thing i don't ultra love about instantaneous enablement, there's no way to actually entirely regenerate the key material
<tpw_rules>
also the VEK and xART are destroyed by a DFU restore, right?
<marcan>
yes
<amarioguy>
yes
<marcan>
(for a DFU wipe, not revive)
<amarioguy>
marcan: isn't revive just running the update ramdisk?
<nicolas17>
does revive even touch the data partition?
<marcan>
tpw_rules: AIUI you can pass in tweak keys per NVMe operation, so if you want that kind of layer you could add it on top and support progressive re-encrypt like LUKS does
<marcan>
amarioguy: probably?
<marcan>
it also reinstalls macOS AIUI
<tpw_rules>
i think it fscks it
<nicolas17>
that may have changed before and after SSV
<marcan>
and also rolls over the lpnh I think or something like that
<marcan>
so it's a pretty big hammer
<marcan>
(I've been advised not to advocate it for firmware updates for macos-less Asahi installs)
<marcan>
we should figure out the proper SFR update ramdisk stuff some day, after we have some semblance of APFS and nvram support
<marcan>
and then we can start offering macos-less installs
<nicolas17>
augh I hate it when internet searches land me on Apple forums
<amarioguy>
i feel like macos-less installs are just asking for trouble
<marcan>
you still have recoveryOS
<tpw_rules>
chadmed: i would appreciate adding the point about DFU wipe destroying the disk encryption keys for those interested
<nicolas17>
"kernel_task is a process to protect your computer from over heating. When heat increase drastically, the kernel_task process is launched by MacOS with high priority to decrease decrease heat generated by the CPU." *dies of cringe*
<marcan>
also if needed you can use recoveryOS to install macOS on an external disk and then use that for further rescue
<marcan>
so it's not that bad
<amarioguy>
gotcha
<chadmed>
nicolas17: verified answer, 36 found this helpful, five stars, etc
<marcan>
(we should *also* support full external Asahi installs some day, we just need a Rust xHCI+USBD implementation)
<amarioguy>
tpw_rules: ditto - it's important to note this
<amarioguy>
(the DFU wipe rotating keys)
<marcan>
DFU wipes also outright low level reformat the NAND as far as I know
<marcan>
so it can recover from totally fscked NVMe FTL state
<tpw_rules>
i assume the FTL is encrypted in some way too
<tpw_rules>
cause it would be dumb not to and you can swap around the m1 studio modules is i guess how you have intuited that
<marcan>
my assumption has been that the entire NVMe is encrypted at some layer, but I don't know where
<marcan>
this is not verified
<tpw_rules>
i wonder if that has implications for wear leveling....
<marcan>
it shouldn't
<amarioguy>
i know apple used to have effaceable storage and such
<marcan>
that's now done in SEP
<nicolas17>
amarioguy: I think that was pre-SEP
<marcan>
with the xARTS
<amarioguy>
gotcha
<amarioguy>
they do still mention media key in some security document gimme a sec
<amarioguy>
> This is achieved by introducing an additional seed bit whose setting governs the ability to access the media key, which itself is needed to access the metadata (and therefore contents of all files) on the data volume encrypted with Data Protection
<amarioguy>
the relevant quote
<nicolas17>
elsewhere it says
<marcan>
amarioguy: that sounds like just for the data volume
<nicolas17>
"When stored, the encrypted file system key is additionally wrapped by an “effaceable key” stored in Effaceable Storage or using a media key-wrapping key, protected by Secure Enclave anti-replay mechanism. This key doesn’t provide additional confidentiality of data. Instead, it’s designed to be quickly erased on demand (by the user with the “Erase All Content and Settings” option"
<amarioguy>
ah right
<amarioguy>
yea we can just toss effaceable out then nowadays
<marcan>
yeah so there's still no actual evidence about whole-NVMe encryption
<marcan>
I might be wrong about that
<marcan>
actually I probably am, because SEPOS is in NVMe and I don't think they'd store that outside SEP?
<marcan>
so maybe it's all plaintext after all
<amarioguy>
i know that nvme firmware partition has to be plaintext
<marcan>
that's in NOR
<amarioguy>
ah right thinking of idevices
<nicolas17>
on boot, is the whole data partition inaccessible until first login?
<amarioguy>
not all of it is inaccessible
<amarioguy>
just anything using class A, B private, and C keys
<nicolas17>
NSFileProtectionNone is "not supported on macOS" according to the security guide
<amarioguy>
not supported != not used
<amarioguy>
they really insist on class C keys for most apps
<amarioguy>
A keys if necessary
<nicolas17>
ah well, it has been discouraged on iOS for years
<nicolas17>
"The basic classes and policies are described in the following sections. Apple silicon-based Mac computers don’t support Class D: No Protection, and a security boundary is established around logging in and out"
<amarioguy>
> NSFileProtectionNone: This class key is protected only with the UID, and is kept in Effaceable Storage.
<amarioguy>
ahh that's why
<amarioguy>
no AS mac without sep
<amarioguy>
so yea class D is tossed out
<nicolas17>
so it needs my account password to decrypt anything in the data partition?
<chadmed>
yeah the KEK is unwrapped with your account password if im reading apples docs correctly
<amarioguy>
yea my tracing of sep corroborates that for the most part
<nicolas17>
okay so
<nicolas17>
where does my language setting, my user account profile picture, and other stuff seen in the login screen come from? :D
<nicolas17>
language setting could be nvram, but user pictures?
<chadmed>
where does rOS get it from?
<marcan>
I think that gets copied over to a plist on the Preboot partition
<marcan>
there are several such plists
<marcan>
the Asahi installer copies one over to the new stub to make kmutil/etc work
<nicolas17>
marcan: ah interesting
<marcan>
since the username->UID mapping is stored there
<chadmed>
do they just dump the picture into the plist as b64?
<marcan>
(presume SEP needs the UID)
<marcan>
yeah, I think so
<nicolas17>
could be a bplist, then there's no b64 :D
<chadmed>
yeah they do a lot of that :D
<amarioguy>
yea that kinda tracks actually
<chadmed>
the audio DSP ones have CoreAudio AU binary data as b64...
<nicolas17>
I know pre-login stuff on iOS (like the lock screen wallpaper) is exactly what the class D key is for
<nicolas17>
so I was stumped when I saw there's no D key on macOS
<amarioguy>
i guess for more security? i mean anything encrypted with D key is for the most part in the clear
mini0n has joined #asahi-dev
<amarioguy>
so the preboot
<amarioguy>
could've given them an out
<nicolas17>
yeah they say class D only gives the advantage of instant wipe by erasing the key
<nicolas17>
btw, the APFS spec lists 6 classes ;)
<nicolas17>
A, B, C, D
<nicolas17>
class F: "The behavior of this protection class is the same as Class D, except the key isnʼt stored in any persistent way. This protection class is suitable for temporary files that arenʼt needed after rebooting the device, such as a virtual machineʼs swap file."
<nicolas17>
class M: <undocumented>
<amarioguy>
chadmed: The tooling signs the resultant binary, and tells the SEP that it is allowed to boot it as the kernelcache for our APFS container. - slight revision - it's sep that signs it not bputil itself
<chadmed>
ah yeah of course
<chadmed>
"The SEP signs the resultant binary, and enrolls it as the kernelcache for our APFS container."
<amarioguy>
bingo
derzahl has joined #asahi-dev
<amarioguy>
other than that, the doc's looking pretty solid to me rn
<chadmed>
thanks for going through it
<amarioguy>
no problem, glad to help
<amarioguy>
marcan: corecrypto and libder for m1n1 secure boot /s
<marcan>
no.
<marcan>
also I just realized the i2c unjam machine was being disabled by the pasemi driver (it's enabled by default but it was clearing that bit...)
<marcan>
enabling that; doesn't explain the i2c failures but explains why they can never recover sometimes
<amarioguy>
marcan: re secure boot - fair enough was more a meme suggestion but oh well
<amarioguy>
also good to know on the i2c stuff
<amarioguy>
do you want me to fix that or smth?
<marcan>
I just fixed it
<amarioguy>
ah got it
<marcan>
we still need to figure out why the codecs have issues on 6.2 though
<marcan>
need to look at that
<amarioguy>
i assume this pertains to audio stuff?
<marcan>
yes
hertz has joined #asahi-dev
<chadmed>
there were a couple of changes to asoc dpcm/dai code but nothing that _should_ cause what we're hearing
<chadmed>
admac still likes to randomly crash too
amarioguy_ has joined #asahi-dev
<amarioguy_>
marcan: my bad for making the whole secure boot joke I honestly forgot briefly about the whole licensing issues and how seriously you take them
<marcan>
it's fine lol
amarioguy_ has quit [Remote host closed the connection]
<marcan>
ahaha I just ran into the funniest "duh" bug
<marcan>
when you have natural scrolling enabled, the volume icon in KDE turns down when you scroll up, and vice versa
<marcan>
I... I don't think that's natural, lol
<marcan>
also affects all sliders and things like that
<eiln>
most "shallow" layer models (of sane, non-gpt density) seem fine
<eiln>
verified pretty much all mainstream classification models (resnet*, mobilenet, inception, etc.)
<nicolas17>
where is that running :O
<eiln>
asahi :)
<nicolas17>
yeah but
<nicolas17>
GPU, ANE?
<eiln>
ANE fully
<marcan>
eiln: niiiiice
<marcan>
is that on m1n1, or actually on Linux?
<eiln>
linux! loaded kernel module on reference distro
<marcan>
very nice!
<eiln>
thank you :))
<eiln>
now trying to port chaining for fatter ones like detection & segmentation..
<marcan>
dammit and here I thought ANE was going to be on my back burner forever, it's what i've been telling people :p
<marcan>
very nice work
<marcan>
do you think it's worth using for non-ML tasks, like image processing?
<marcan>
eiln: also you should toot that :-)
<marcan>
(meanwhile I hear lina is doing GPU compute today, so maybe that'll cover the training side? :p)
<eiln>
havent got to benchmark anything yet but i do see it being useful for general linalg passes
<lina>
^^
<lina>
(also I got pinged by "linalg" www)
<eiln>
they designed it with cnn's in mind, so it's rlly well fitted for image processing
<eiln>
hehe
<eiln>
color space conversion seems very feasible too imo
<marcan>
yeah, makes sense (though we already have a fancy scaler block for that, once someone figures *that* out)
balor has quit [Quit: balor]
balor has joined #asahi-dev
nicolas17 has quit [Quit: Konversation terminated!]
<chadmed>
elin: congrats! very impressive getting this far in what feels like no time at all really
<eiln>
chadmed: thank you :)) nice work on audio too
<eiln>
from what ive seen the selling point is power-efficiency over raw speed
<chadmed>
eiln: thanks :) as soon as we get that second PCM exposed for V/I readings we can start enabling devices!
<eiln>
marcan: actually DCT/DST transforms seem very doable, let me see if i can some up with a temporary jpeg/scaler block for the meantime ;)
<chadmed>
makes sense re efficiency of the ANE. it's mostly used in the iphone for background image processing for things like text search indexing and post processing, neither of which need to be blisteringly fast
<chadmed>
id rather the phone not get hot when its tagging images for "monkey dancing on a bouncy ball"
hertz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<eiln>
the speed numbers are pretty mediocre, considering they do a repo's worth of surgery on top of their closed-source framework
<eiln>
they repetitively emphasize power consumption though, "executing on a device that is orders of magnitude more energy-constrained"
<eiln>
related, the coreml "device distribution algorithm" 100% favors NPU
<chadmed>
makes sense to me, its like how they had crap raw perf gains going from Firestorm to Avalanche so for the first time literally ever went "uhh yeah we're faster than qualcomm actually"
<eiln>
CPU layers are fallback for passes their compiler hasn't implemented yet lol not because it's more efficient or whatever
<eiln>
e.g. Hardswish function in MobileNetV3 isn't implemented, so it goes NPU --deswizzle--> CPU Hardswish --reswizzle--> NPU, quadrupling the time from MobileNetV2 which is fully NPU
<eiln>
does make me think there could be perf gains w/ dedicated kernels for common routines
hertz has joined #asahi-dev
balor has quit [Quit: balor]
balor has joined #asahi-dev
SSJ_GZ has joined #asahi-dev
leitao has joined #asahi-dev
leitao has quit []
eiln has quit [Quit: Page closed]
hertz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
capta1nt0ad has joined #asahi-dev
<dottedmag>
chadmed: Very nice writeup. Is there another place that grounds the terms used in it to the actual bits? I'm looking for something like "per-container boot polices are files this and that on partition foo" and "blessing means creating a signature using this key over hashes of these files and storing it in here"
tim has joined #asahi-dev
tim is now known as Guest1321
capta1nt0ad has quit [Ping timeout: 480 seconds]
<chadmed>
dottedmag: the glossary should have some of that stuff, if theres stuff missing ill add it
kujeger has quit [Ping timeout: 480 seconds]
<dottedmag>
chadmed: To use these examples: blessing is not in glossary, and boot policy is mentioned in SEP article, but not on its own. More important, glossary says "what thing is", not "where do I find it when I look at the system, and what does it contain"
capta1nt0ad has joined #asahi-dev
<Cyrinux>
marcan suspend on m2 air ok now, thx !
bps2 has joined #asahi-dev
kujeger has joined #asahi-dev
<chadmed>
another huge dub for audio quality and efficiency: pipewire has been fixed to accept multiple IRs at multiple sample rates to cut down on resampling, which introduced some really gnarly artefacts (and cost way too much cpu time)
<chadmed>
the compressor is still an enormous cpu hog but i dont think we really have a way around that if we would like to preserve our speaker cones :/
dsharshakov has joined #asahi-dev
<dsharshakov>
chadmed: glad to be helpful ;)
<chadmed>
i had to revert one of wim's commits to test it, he broke spa arm cpu detection with some bad pointer logic
<dsharshakov>
How much more efficient is the pipeline on macOS? Maybe the task cannot be more efficient
<chadmed>
so the problem right now is that we dont have a psychoacoustic bass plugin to cut down on how much we need to move the cone
<chadmed>
apple cut out most of the "real" low end and turn it over to funky biquad harmonics, which means they dont need the same ridiculous multiband compression setup i have right now to tame down the low end at high input volumes
<chadmed>
because the cone just doesnt move enough to smack against the chassis
<dsharshakov>
Re arm detection: already has an MR. Likely will be pending till Monday. Let's find out who will be the commiter #10000r
<dsharshakov>
Understood the compressor thing
<dsharshakov>
Well
<chadmed>
when i use just a normal blanket compressor to limit the volume for clipping/safety reasons, the cpu cost is about identical to macos
<chadmed>
but the multiband nonsense im doing now uses... a bit more :P
<dsharshakov>
I might take a look at lv2 host and module loading, maybe something to optimize there or inside lsp itself
<sven>
eiln: nice work!
<chadmed>
i imagine it would be the plugin itself rather than the host, its just a very costly operation especially with lookahead
<dsharshakov>
What does the psycoacoustic bass thing really do? Maybe capture its in/out somehow to understand what is the synonym for it
<sven>
tpw_rules: / marcan: ANS can take a aes-xts key for each read/write command in that TCB structure. that key can (must? didn'ttest yet) be entangled by SEP. so you essentially send the encrypted keybag to SEP, SEP authenticates it and then gives you back the entangled volume key that you pass to ANS
<chadmed>
theres a commercial version of it called MAXXBASS or something
<sven>
each reboot changes that entangling ofc so that you can't just grab the key once and keep using it forever
<chadmed>
would you believe me if i said i have done this without any macos RE, i just know vaguely what it does :P
<chadmed>
so i have no idea how id capture what the AUs are doing, ive done all this by ear :P
<dsharshakov>
I would for sure
<dsharshakov>
Maybe Calf Studio bass enhancer would help?
<dsharshakov>
Not at PC rn, will explore later
jluthra has quit [Remote host closed the connection]
jluthra has joined #asahi-dev
<chadmed>
i dont really want to introduce any more runtime dependencies tbqh. im more than happy with the sound quality without the fake bass (in fact, it sounds better than macos right now), its just the cpu use that kinda blows
<dsharshakov>
chadmed: when possible, please respond to pv on the PipeWire issue about IR resampling quality: maybe some fix could be done there as well (for other use cases)
<chadmed>
on it right now
<dsharshakov>
:+1: thanks
dsharshakov has quit [Remote host closed the connection]
<jannau>
sven: is there a reason why the nvme_disable in apple_nvme_reset_work() is done before (re-)starting rtkit?
SSJ_GZ has quit [Read error: No route to host]
<sven>
hrm, let me check
landscape15 has joined #asahi-dev
<marcan>
chadmed: AIUI the bass enhancer stuff just adds harmonics, effectively. so, saturation.
<mps>
chadmed: interesting thing found: with kernel 6.2-rc3 and playing sounds on jack, with alsamixer when switching in headphone playback mux to secondary and back to primary sound distortion disappears
<marcan>
probably multiband to some extent
<mps>
chadmed: I don't use pulseaudio nor pipewire
<sven>
jannau: to cleanly shut down rtkit i think
<marcan>
it's for the "we are alive -> reset" path
<sven>
iirc also for old m1n1 or uboot that kept nvme alive before jumping to Linux
<sven>
*older
<mps>
marcan: ah, thanks
<chadmed>
marcan: sounds (and feels) like they cut down the fundamentals. its what youd normally do with such tiny speakers to stop precisely the issue we're having
<jannau>
ok, that means we have to do the reset in suspend anyway to shut rtkit down cleanly
<marcan>
chadmed: right, after saturation
<chadmed>
mps: yeah the problem is definitely in the kernel. wouldnt surprise me if its asoc doing something silly with the frontend channels and their relationship to tdm slots in the backend
<marcan>
which is what makes it sound thick without the fundamental
<chadmed>
yeah
<jannau>
the only signigficant difference I see with cs42l84 codec tracing is that PLL_LOCK_STATUS changes from 0x10 to 0x30
<mps>
chadmed: could this in dmesg output be related: 'tas2764 3-003c: Unable to sync registers 0x1-0x4. -6'
<chadmed>
mps: no thats the speaker codecs not suspending properly because of shared gpio nonsense
<jannau>
no, tas2764 is the speaker codec
<mps>
aha
<chadmed>
my PR against asahi-wip fixes that for tas2764 but supposedly still doesnt work for tas2770
<chadmed>
i should submit v2 of that upstream (minus the shared gpio fix)...
<mps>
chadmed: fine, when you have it please post url also to me, I'm ready to test patch
<sven>
also, lol, apple calls their thunderbolt domain “iOS” on the m1 :D
landscape15_ has joined #asahi-dev
<sven>
or, well, actually their root switch I guess
<chadmed>
did you play something through the speakers before suspending?
<mps>
no
<chadmed>
ah interesting
<mps>
just through jack
<chadmed>
so someone else reported that it still breaks if nothing's been played through the speakers before suspend is attempted too
<chadmed>
interesting that it fails to sync all of them
<chadmed>
usually its only a few
<chadmed>
could you try playing something briefly, suspending, then resuming the system?
<mps>
yes, I did
<chadmed>
all codecs still fail to come back up?
<mps>
failed
<chadmed>
hmph
<mps>
but this time I played through speakers
<chadmed>
i wonder if the SDZ pins are connected differently on j316
<chadmed>
and the hack i used that worked on j314 doesnt work there
<chadmed>
because of the timings
<chadmed>
that would mean the only way to fix this consistently is to march back into the shared gpio bike shed
<chadmed>
which... nope not doing that
<mps>
playing through jack sounds came back after suspend
<chadmed>
yeah the jack has always worked
<chadmed>
these patches are just for the speaker amps
<mps>
and distortion is still there
<chadmed>
yeah, i need to look deeper into that
<chadmed>
but i have a feeling its something that got changed in core asoc code that handles tdm slot allocation on driver initialisation
<chadmed>
since you said switching playback muxes cleared the problem
<mps>
yes, that is strange
<mps>
waiting for Glanzman to test
<mps>
if he can confirm this
<chadmed>
i replicated it on my machine so its def a kernel problem
<mps>
ah, ok. you also have j316
<chadmed>
i have a j314 but they use the same jack driver chip
Guest1321 has quit [Quit: Guest1321]
landscape15 has joined #asahi-dev
landscape15 has left #asahi-dev [#asahi-dev]
chadmed_ has joined #asahi-dev
sah4ez has joined #asahi-dev
SSJ_GZ has joined #asahi-dev
sah4ez has quit [Read error: Connection reset by peer]
mini_ has quit [Quit: ZNC closing...]
mini_ has joined #asahi-dev
landscape15 has joined #asahi-dev
landscape15 has left #asahi-dev [WeeChat 3.8]
landscape15 has joined #asahi-dev
capta1nt0ad has quit [Remote host closed the connection]
landscape15 has left #asahi-dev [WeeChat 3.8]
SSJ_GZ has quit [Remote host closed the connection]
SSJ_GZ has joined #asahi-dev
<sven>
now that looks better: ?? uuid: 01971875-8660-0100-ffff-ffffffffffff
<sven>
now if only the pcie port would come up :D
landscape15 has joined #asahi-dev
tim has joined #asahi-dev
tim is now known as Guest1344
sah4ez has joined #asahi-dev
landscape15 has quit [Quit: WeeChat 3.8]
sah4ez has quit [Remote host closed the connection]
faruk has joined #asahi-dev
derzahl has quit [Remote host closed the connection]
roxfan has quit [Ping timeout: 480 seconds]
flying_sausages has quit [Ping timeout: 480 seconds]
bps2 has quit [Ping timeout: 480 seconds]
c10l has quit [Quit: Bye o/]
c10l has joined #asahi-dev
bps2 has joined #asahi-dev
roxfan has joined #asahi-dev
bps2 has quit [Ping timeout: 480 seconds]
mini0n has joined #asahi-dev
bcrumb has joined #asahi-dev
faruk has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bcrumb has quit [Ping timeout: 480 seconds]
<povik>
chadmed: can you give a summary of the jack distortion issue? between which tags it appeared?
<jannau>
povik: asahi-6.1-3 and asahi-6.2-rc2-1 and still present in later asahi-6.2-rc* tags
<jannau>
so introduced with the rebase onto v6.2-rc2
<jannau>
sanity check on our changes doesn't show any differences in the codec or device tree
<jannau>
cs42l83 (j274) has no distortion
<povik>
huh
<povik>
thanks
<jannau>
only difference I see in a codec trace is a couple of additional "REG: W.8 CCM_CTRL1 = 0x0 (MCLK_SRC=0(RCO), MCLK_FREQ=0(F_12MHZ))" writes
<jannau>
and "REG: R.8 PLL_LOCK_STATUS = 0x30" instead of 0x10
<jannau>
mps said switching the headphone playback mux to secondary and back to primary fixes the distortion (without pipewire/pulseaudio). on j375 with pipewire running that doesn't fix the distortion
<povik>
right, i guess something changed in sequencing of calls causing a clock misconfiguration
<povik>
0x20 will most likely be the locked flag in the pll status register
<povik>
let's check
<jannau>
no, 0x10 is the locked bit
<povik>
huh
<jannau>
0x20 is appears in the broken v6.2-rc* builds