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
amarioguy has quit [Remote host closed the connection]
ricekot has joined #asahi-dev
ricekot has quit []
greguu has joined #asahi-dev
hertz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hertz has joined #asahi-dev
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
chadmed_ has quit [Remote host closed the connection]
<d4ve>
hey all- I need CONFIG_FTRACE=y for some eBPF observability work. So far I've just been recompiling the kernel with a modified config, but that gets tedious. Is there any chance of getting that enabled, and how would I go about proposing that?
tim has joined #asahi-dev
tim is now known as Guest1483
balor has quit [Ping timeout: 480 seconds]
<povik>
dsharshakov: basically the argument against AOP is: (1) i would rather support a hardware interface than a firmware interface; (2) we have more control over the stream if we program LEAP ourselves
<povik>
as to your other question, AOP doesn't do beamforming, it hands over an isolated stream from each mic
bps2 has joined #asahi-dev
hertz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leitao has joined #asahi-dev
pg12_ has joined #asahi-dev
pg12 has quit [Ping timeout: 480 seconds]
jluthra has quit [Remote host closed the connection]
jluthra has joined #asahi-dev
bps2 has quit [Ping timeout: 480 seconds]
tim has joined #asahi-dev
tim is now known as Guest1490
Guest1483 has quit [Ping timeout: 480 seconds]
bisko has joined #asahi-dev
dsharshakov_ has joined #asahi-dev
<dsharshakov_>
povik: thanks. (1) is obvious (likely the firmware is changing continuously with each macOS version). However, what (2) gives you extra?
dsharshakov_ has quit []
<povik>
well, we don't know how likely it is for the firmware interface to change...
<povik>
and a counterargument is that the apple's firmware might abstract away a hardware difference on future models
<povik>
so it's not so clearcut
<povik>
anyway, re (2), we can at least disable some of the channels, if a single mic is all userspace can cope with
bps has joined #asahi-dev
<povik>
and then there's the option of inserting more processing onto LEAP
dsharshakov has joined #asahi-dev
<chadmed>
could LEAP do multiband compression :P
<dsharshakov>
are other AOP nice features useful for us? AFAIK it can wake the system up on some events, what else?
<chadmed>
"hey siri" functionality (useless)
<dsharshakov>
since if it will be needed later, its introduction will duplicate the works and block us from access to LEAP
<chadmed>
and probably airtag-like functionality for Find My (also useless)
<dsharshakov>
airtag-like functionality is likely to live on its own broadcasting everytime
<povik>
yeah, i am curious to what degree is "hey siri" implemented on LEAP
<povik>
my guess is that it gives some initial low-confidence signal
<povik>
that then wakes up AOP which confirms the detection
<sven>
AirTag stuff might also be mostly implemented inside the Bluetooth firmware
<dsharshakov>
sven: I've read it's shared between AOP and BT. Likely they be beaconing 100% independently from the OS
<dsharshakov>
AOP somehow sets configs and gives keys as well
<sven>
hrm, that sounds weird because then AOP would need a backchannel to the bt module
<povik>
dsharshakov: well, as to the other features of AOP: the only thing that comes to mind is that it reports the lid angle to the OS
<povik>
that's at least on j316 i am experimenting on
<povik>
but then there's a gpio line on gpio-aop which reports opened/closed lid
<povik>
which might be good enough for all our purpouses
<povik>
not sure if wake-on-lid-open doesn't work already
<chadmed>
not under linux no
hightower2 has quit [Ping timeout: 480 seconds]
<povik>
ah, i can give the gpio we need to wake on :p
<chadmed>
the smc has the hid event for the lid closing/opening but hid events seem to get suspended and the only way to wake the thing is with the hard power button
<chadmed>
just like my old northwood p4 machine :P
* povik
looks for a binding we may get away with filling it in
<povik>
nothing obvious so far
dsharshakov has quit [Quit: Page closed]
<povik>
hm, not sure how this stuff is exposed internally in the kernel or to userspace
<povik>
i will leave it be for now
<chadmed>
dsharshakov: on mb compressor optimisation, all the dsp paths in lsp-plugins are written in assembly
<ChaosPrincess>
sven: apparently it does on iphones
<chadmed>
yeah, the headers in include are the assembly
<dsharshakov>
either the core capacity for icestorm is lower or it still lacks some opt on AArch64
<sven>
ChaosPrincess: that’s… very odd
<povik>
there's the backchannel?
<sven>
I could maybe see AOP doing some power Management but I’d be very surprised if it did more than that for bt
<dsharshakov>
Maybe make compressor only kick in when loudness is higher than x? Might be clicky in that case...
<chadmed>
yeah that seems sus and would ruin lookahead
<sven>
like, the sane way to do this is to have the AP pre-program the find my beacons in the BT chip and then put the BT chip to sleep. and then either BT has a timer to wake itself up or AOP wakes it up periodically to send those beacons
<chadmed>
in my testing the core power use is less than 4 W playing music through vlc with the dsp active, and this is without cpuidle so the pcores are still freewheeling
<chadmed>
its not that big of a deal at the end of the day, there are bigger targets to attack for power savings
<dsharshakov>
yes. However, let it sit in our thoughts, maybe I or you can figure out a newer option
<dsharshakov>
Probably when WirePlumber loads that filter it should be run within one wakeup (sound from pw-pulse -> *WKUP* -> filter in in wp -> ALSA plugin in WP -> *switch to kernel*
<dsharshakov>
what's the net power difference when removing the mb compressor?
hightower2 has joined #asahi-dev
<chadmed>
falls into noise since the pcores freewheeling are using most of the measurable power
<ChaosPrincess>
sven: schematic says that there is a spmi link between aop and wifi chip. could that be the 'backchannel'?
<chadmed>
the smc's meters are pretty accurate but not THAT accurate
<chadmed>
i think itll be a bigger deal once we have deep idle
<chadmed>
but for now its all academic but worth talking about
<povik>
ah, that's the gpu, not the neural coprocessor, right?
<j`ey>
no thats the ANE
<eiln>
no ANE!
<povik>
really? that progressed pretty far then, being able to run a full network
<eiln>
still relatively shallow networks only though, currently working on chaining buffers
cylm has quit [Ping timeout: 480 seconds]
hightower2 has quit [Ping timeout: 480 seconds]
chadmed_ has joined #asahi-dev
faruk has joined #asahi-dev
<sven>
ChaosPrincess: sounds like AOP maybe takes care of waking up BT then
faruk has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
chadmed_ has quit [Remote host closed the connection]
chadmed_ has joined #asahi-dev
faruk has joined #asahi-dev
kit_ty_kate has joined #asahi-dev
seeeath has joined #asahi-dev
flying_sausages has quit []
faruk_ has joined #asahi-dev
faruk has quit [Ping timeout: 480 seconds]
flying_sausages has joined #asahi-dev
<marcan>
povik: AIUI AOP also reports accelerometer data on at least some models
<marcan>
personally I'm more of the opinion that we should do whatever macOS does, even if it involves firmware, because diverging from that is more likely to come crashing down in bad ways with updates
<marcan>
e.g. consider what happens if AOP starts talking to other firmwares or doing something special
<marcan>
that depends on the specific hardware involved though
<marcan>
why do we care about LEAP even? if we're bypassing things, can't we just get the raw mic data before LEAP?
hightower2 has joined #asahi-dev
<marcan>
< sven> like, the sane way to do this is to have the AP pre-program the find my beacons in the BT chip and then put the BT chip to sleep. <- this is exactly how it works or at least how it worked at some point, for iPhones when they *shut down*
<marcan>
however I don't know what happens during normal idle, clearly not that
<marcan>
maybe AOP is in charge during normal idle and the AP programs the beacons for full standalone mode on transition to actual shutdown?
<sven>
hrm, or maybe the BT chip stays somewhat alive in normal idle for wake-on-bluetooth anyway and does everything itself?
<marcan>
chadmed: the cores don't "freewheel", they do go into idle, just not deep idle
<marcan>
we aren't spinning lol
<marcan>
I think what happens is the cores shut down their clocks when you do that but not the cluster uncore
<marcan>
(and everything remains powered)
<marcan>
the major reason why we have power usage proportional to pstate is probably just leakage current that comes with the higher voltage, not the actual frequency
<marcan>
going into deep idle should power gate individual cores or the whole cluster if all cores are in that state, which will save all the leakage current
<marcan>
< chadmed> not under linux no <- what yes it does
<marcan>
wake on lid works perfectly fine
<marcan>
(using the SMC event)
<marcan>
if it doesn't work on some machines I'd like to know :p
<kettenis>
marcan: In case you missed it, I pushed a branch with my current u-boot PCI XHCI work
<marcan>
kettenis: saw that, was going to mention we should probably blacklist the asmedia controllers until we support the firmware loading, and we need to talk about how to pass the firmware to u-boot
<kettenis>
I'm a little bit worried about what happens on the asmedia controllers without loading firmware though
<kettenis>
reading the firmware from NVMe will be a challenge
<marcan>
AIUI they play dead and time out a bunch of things, so best case it slows everything down, worst case it triggers badness
<marcan>
kettenis: right, can we pass it to u-boot directly? it wouldn't be hard to append it to the m1n1 image (e.g. as a ramdisk) as part of the install process / m1n1 update
<kettenis>
passing the firmware in memory and putting the addresses in the device tree would make things easier on my end
<marcan>
can u-boot do anything useful with an initramfs passed to it?
<marcan>
initramfs would be easiest because we already have that functionality in and it mirrors how it works for linux
<kettenis>
don't think u-boot does initramfs, but I can have a look
<marcan>
IIRC it's just a /chosen property with the address/size
<marcan>
would be nice if we taught u-boot how to minimally parse cpio (it's a very dumb format, and specifically only the version Linux understands) so we can just give it a subsetted vendorfw.cpio with just the components it needs (USB for now) and avoid a totally divergent mechanism
<kettenis>
but it is in cpio format isn't it?
<marcan>
cpio is really dumb
<marcan>
kettenis: see driver-api/early-userspace/buffer-format.rst for a formal spec of the specific variant we care about
faruk_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marcan>
we can skip hardlink support for u-boot (I can at least guarantee we either never omit file contents or duplicate them for u-boot archives if it ever becomes necessary)
<marcan>
at that point parsing it is just parsing some hex numbers and looking for the filename you want
<kettenis>
right, sound doable
<kettenis>
and then the idea is to just cat the initramfs to boot.bin on the ESP?
<marcan>
and since m1n1 will uncompress the initramfs for us (if compressed) you don't need to care about that either
<marcan>
yeah
<marcan>
the installer can just build a uboot-subset initramfs and tack it on at install time, update-m1n1 can do the same at update time
<povik>
marcan: i thought the accelerometer is unpopulated
<povik>
or is it on m2 macbooks that they started to put it in?
<marcan>
povik: I think it might be populated on at least some models
<marcan>
I've seen it in some ADTs I think
<povik>
anyway we don't want to bypass LEAP because it does the PDM-to-PCM decimation
<povik>
the raw data it processes is a 2.4 MHz PDM stream
<ChaosPrincess>
marcan: if you have time, mind looking at the z2 driver draft and checking if im not doing anything super dumb
<kettenis>
I'll need to teach the OpenBSD installboot about this trick, but that should be doable
<kettenis>
(not sure I mentioned it here, but OpenBSD now automatically updates boot.bin on the ESP)
<kettenis>
anyway, if someone could test my current u-boot branch on an iMac or Mac Studio I would be grateful
<marcan>
povik: j314/j316/j493 have accel/gyro nodes under aop
<marcan>
interestingly so does the m1 studio... which makes me wonder, but I wouldn't put it past apple to put an accelerometer in a desktop
<kettenis>
it's probably just part of one of the chips they need for other purposes
<marcan>
nah, I think it was a discrete part in the schematics
<marcan>
IIRC it was designed in but unpopulated in the original m1 series, but it looks like they actually started populating it in m1pro/max unless the ADT lies
<povik>
huh, i got the impression on j314 it's unpopulated
<povik>
at least i haven't seen anything that looks like imu data that AOP sends to macos
<povik>
there were periodic lid angle measurements, so if the accelerometer was there, i would expect something similar
<marcan>
they probably don't actually enable it?
<povik>
there's an endpoint for it, i think it gets enabled, not sure anymore
<marcan>
chadmed: tested wake on lid open on j314 too, works fine
<kettenis>
btw, we (OpenBSD) have gone execute-only .text on arm64
<kettenis>
been an interesting experience (and yes I know about the PAN issue)
<marcan>
nice :)
hertz has joined #asahi-dev
<sven>
$ boltctl list
<sven>
? Apple Thunderbolt to Gigabit Ethernet Adapter
<sven>
still doesn't show up in pcie though
<marcan>
nice :D
<kettenis>
hmm, how can it identify the adapter without pcie config space access?
<sven>
huh.. good question
<povik>
:D
<maz>
separate enumeration mechanism?
<maz>
over usb? (making things up...)
<sven>
let me test again, maybe i just confused myself and it did show up
<marcan>
doesn't thunderbolt have its own enumeration at the thunderbolt level?
<sven>
I think there might be a separate enumeration at tbt level though
<sven>
yeah
<marcan>
so it'd be identifying the TB device connected, not the PCIe device behind it
<sven>
probably, it does have a UUID in boltctl as well that had to come from *somewhere*
<kettenis>
heh, shows how little I know about thunderbolt
<marcan>
yeah, pretty sure it's the idrom thing or whatever they call it
<maz>
feels like it needs to trigger a rescan of the PCIe config space -- hotplug style.
<povik>
btw, how does the wake on lid open work? does userspace configure hid events that should wake the system, and kernel does some filtering and possibly returns to sleep?
<sven>
yeah, i have code for the hotplug that "works" for the bt/wifi thing but doesn't for thunderbolt for some reason
<sven>
probably another magic bit that needs to be set somewhere
<kettenis>
sven, this is using your 2-3 converter?
<sven>
yes
<kettenis>
maybe I should get one since I have an old thunderbolt 2 ethernet dongle lying around
<maz>
does writing to "/sys/bus/pci/rescan" trigger anything?
<sven>
nope. I've also never seen a port up event for the tbt root port so far
<maz>
meh
<sven>
this smells like some "enable pcie tunnel" poke is missing somewhere
<marcan>
povik: it's hardcoded in the SMC driver :p
<marcan>
it just considers the power button and lid open as unconditional resume events
<sven>
kettenis: the apple one is pretty cheap these days (50 eur or so) fwiw
<kettenis>
not my definition of cheap ;)
<sven>
heh, fair
<povik>
marcan: so you can't not wake at the moment?
<kettenis>
but probably my cheapest option to get a thunderbolt 3 device
<marcan>
correct
<marcan>
I think there is some general wakeup source control we could implement, not sure if there is a mechanism to outright pick specific HID events though
<povik>
hm, how can it not work for chadmed though
<marcan>
no idea :p
<povik>
is it possible this depends on some setting from macos?
<marcan>
not really
<marcan>
these are standard SMC events
<marcan>
remember this isn't real idle
<marcan>
if the HID events work while the thing is running there's no reason they'd stop working during s2idle
<marcan>
SMC doesn't know the difference
<povik>
right
Guest1490 has quit [Quit: Guest1490]
eiln has quit [Quit: Page closed]
faruk has joined #asahi-dev
leitao has quit [Ping timeout: 480 seconds]
leitao has joined #asahi-dev
hightower2 has quit [Read error: Connection reset by peer]
bcrumb has joined #asahi-dev
bcrumb has quit []
bcrumb has joined #asahi-dev
bcrumb has quit []
bcrumb has joined #asahi-dev
bcrumb has quit []
bcrumb has joined #asahi-dev
bcrumb has quit []
cylm has joined #asahi-dev
<sven>
okay, with sone ugly hacks it also shows up on the pcie bus now. now I’ll just have to see how to work around the „dart MMIO only comes up after the pcie port is up“ and add support for that tbt dart MMIO layout
<sven>
*some
hightower2 has joined #asahi-dev
eiln has joined #asahi-dev
bcrumb has joined #asahi-dev
bcrumb has quit []
bcrumb has joined #asahi-dev
faruk has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hightower2 has quit [Ping timeout: 480 seconds]
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]