nicolas17 has quit [Remote host closed the connection]
derzahl has quit [Remote host closed the connection]
e1eph4nt has joined #asahi-dev
skipwich_ has quit []
skipwich has joined #asahi-dev
pyropeter3 has joined #asahi-dev
pyropeter2 has quit [Ping timeout: 480 seconds]
e1eph4nt has quit [Ping timeout: 480 seconds]
<marcan>
I use moduleless kernels for my servers (for security/simplicity). It's a lot more practical for a sever where the hardware never changes and there is no hotplugging of random devices.
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
yuyichao_ has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
pyropeter3 has quit [Quit: WeeChat 3.1]
yuyichao_ has joined #asahi-dev
mxw39 has joined #asahi-dev
mini0n has quit [Read error: Connection reset by peer]
cuolin^ has quit [Remote host closed the connection]
mxw39 has quit [Quit: Konversation terminated!]
<DmitrySharshakov[m]>
Since many usecases include Mac mini or Mac Studio as a server/build machine, this option should be considered a useful one
<DmitrySharshakov[m]>
So CONFIG_APPLE_KTRR could be added which depends on !CONFIG_MODULES
<DmitrySharshakov[m]>
And maybe even ship such sealed kernels, idk. I think many people would be fine with internal hardware + standard USB classes support for some super extended security
e1eph4nt has quit [Ping timeout: 480 seconds]
<marcan>
yes, that is a viable thing
<marcan>
but again we're talking about very niche spinoffs that don't really make sense to think about now :)
<marcan>
let's get the hardware supported first and worry about special-purpose kernels and niche security setups later
<marcan>
right now, I think our priority after the hardware support is decent should be to support reasonable secure boot (i.e. chaining into existing secure boot paradigms), SEP-assisted FDE/unlock, and also Fedora Silverblue as a proof of concept that Linux can also do the macOS SSV thing
<DmitrySharshakov[m]>
marcan: of
<DmitrySharshakov[m]>
> <@_oftc_marcan:matrix.org> let's get the hardware supported first and worry about special-purpose kernels and niche security setups later
<DmitrySharshakov[m]>
* ofc
<DmitrySharshakov[m]>
What's the state of multiarch in Fedora? I haven't investigated it deeply, but looks like you cannot have x86_64 libs on aarch64 system, so emulation will require a separate dir for libs
<mps>
I doubt that any distro will build special purpose kernels
<DmitrySharshakov[m]>
Yes, but a config option could be added for people who have special usecases
<DmitrySharshakov[m]>
E.g. an extra hardened home server. User could build without module support but with KTRR on their own
<mps>
well, I maintained for some time special kernels for some arm SoCs on alpine linux but stopped few months ago, always someone ask to enable something and someone to disable something
<mps>
though I still build them for my machines
<DmitrySharshakov[m]>
Shipping those is a no-way of course, that'll get crazy as people will try to convince you that all of them use some weird joystick and you should ship the driver builtin xD
<mps>
right
<DmitrySharshakov[m]>
So leave that choice to pro users
<Dcow[m]>
that's sound like genkernel+hardened tool
<mps>
long ago I used LIDS patches to kernel for servers which allowed load modules on boot and lock it in that state, so later modules can't be loaded
<mps>
long ago == 20 years
<mps>
now there is lockdown option but I didn't tested it even
<chadmed>
has anyone had a look at AVD since R last did? ive been reading the exynos codec v4l2 driver and from what i remember of her initial RE efforts it seems similar to that
skipwich has quit [Ping timeout: 480 seconds]
duban has quit [Quit: I'm out]
duban has joined #asahi-dev
skipwich has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
<marcan>
*their
<marcan>
chadmed: don't think anyone has looked at it, though some exynos legacy would not be unexpected...
Race has joined #asahi-dev
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
<dottedmag>
Dcow[m]: Is Fedora Asahi channel bridged to IRC?
<sven>
I think it’s matrix only
e1eph4nt has quit [Ping timeout: 480 seconds]
<dottedmag>
(obligatory XKCD IRC reference)
WindowPain_ has quit [Remote host closed the connection]
e1eph4nt has joined #asahi-dev
WindowPain has joined #asahi-dev
jakebot602 has joined #asahi-dev
jakebot60 has quit [Ping timeout: 480 seconds]
jakebot602 is now known as jakebot60
benpoulson has joined #asahi-dev
benpoulson has quit [Remote host closed the connection]
Stnby[m] has joined #asahi-dev
<_jannau_>
povik: j493 adt has 'amp-dcblocker-config = 16641' in the speaker node if you can make any sense of it
uniq has joined #asahi-dev
<DmitrySharshakov[m]>
Do other machines have adt props for amp safety settings?
<DmitrySharshakov[m]>
btw which speaker has that prop, where's the whole atd dump?
<DmitrySharshakov[m]>
I guess there should be 2 speakers with this config and 4 with another or the other way around
<DmitrySharshakov[m]>
Probably that's a custom bitmask
<_jannau_>
please look at the ADT. there is a general speaker node holding references to all speakers. the macbook pro 13" has just 4 speakers
<DmitrySharshakov[m]>
Where can I look?
<DmitrySharshakov[m]>
upd it appears that it enables 2 Hz filter on both playback and rec, as well as enabling either IRQZ pullup or edge rate control
<DmitrySharshakov[m]>
(derived info from the datasheet, depends on how they order MSB and LSB into registers
leitao has joined #asahi-dev
<povik>
we have a whole tracing infrastructure, we know what macos configures
<povik>
this is a matter of identifying it with adt, possibly simplifying the work
<DmitrySharshakov[m]>
Yes
<povik>
since we can look up something in adt instead of obtaining a trace for every model
<DmitrySharshakov[m]>
Appears that it's edge rate control (enabled by default after reset)
<DmitrySharshakov[m]>
Do other models have these node?
<povik>
what you mean, the 16441?
<povik>
all models will have the nodes
<DmitrySharshakov[m]>
Where can ADTs be found online?
<DmitrySharshakov[m]>
povik: yea, decoded it with the datasheet table
<povik>
ehm, marcan has some of them uploaded
<povik>
you can search the irc logs
<DmitrySharshakov[m]>
Probably on private gists?
leitao has quit [Read error: Connection reset by peer]
leitao has joined #asahi-dev
<povik>
_jannau_: yeah, i can't make sense of it
<povik>
from the trace it sets 0x1 (the default) to the register on all speakers
<povik>
so far i haven't seen macos write anything other there
<DmitrySharshakov[m]>
Yes, ERC is 1 after chip reset by default, so it doesn't change
<povik>
surprising they have a prop for it on j493, i don't see one on j314, where i would reckon the 'dc blocker' is potentially more interesting to set
<DmitrySharshakov[m]>
they might've invented the idea of saving this in the DT after j314 got released
<DmitrySharshakov[m]>
probably earlier they just set the value hardcoded in the driver
c10l has quit [Quit: Bye o/]
c10l has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
leitao has quit [Ping timeout: 480 seconds]
<sven>
marcan/jannau: any reason the iboot protocol wouldn’t work for dcpext?
Swiftloke has quit [Remote host closed the connection]
<marcan>
so I think the iboot thing is a red herring, you should keep using that (since it's easier) and look into the other EPIC endpoints
<marcan>
it's possible the crossbar is a literal N:M of wiring? and so the dcp side has to choose the route to a given ATC, and the ATC has to choose the route from that DCP, on both ends
<sven>
yeah, that would make sense
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
dmmcf has quit [Quit: dmmcf]
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
yuyichao has joined #asahi-dev
yuyichao_ has quit [Ping timeout: 480 seconds]
nafod has quit [Remote host closed the connection]
nafod has joined #asahi-dev
<sven>
yeah, it's clearly talking to AppleDCPDPTXRemotePort
<sven>
and here I thought I could just ignore whatever is going with DCP :D
<marcan>
sven: let me get you some code
<marcan>
it doesn't seem to actually do anything with RemotePort
<marcan>
but it does initialize it, maybe that's enough
<sven>
I see a lot of <Ch 0 Type NOTIFY Ver 2 Tag 625 here for that port
<sven>
whatever that is
<marcan>
so a DCPDPDevice is apparently supposed to magically appear
<marcan>
yes
<marcan>
but the only commands before that are GetLocation and GetUnit
<marcan>
so maybe it just wants that endpoint initialized
<marcan>
hooking it up now, I need some refactoring because indeed, there are 2 instances of everything here
<sven>
sounds good, I do see a few commands at the beginning I think.
<sven>
but I don't quite understand what's going on yet
* sven
has managed to successfully ignore anything DCP so far
<sven>
there's e.g. some command followed by [cpu5] [DCPTracer@/arm-io/dcpext] [syslog] * [AppleDCPDPTX.cpp:361][AFK]powering nub 0x8553a8
<marcan>
yes, but those are just those requests
<marcan>
so I get the feeling this is just the endpoint coming up
<marcan>
and now I wonder, because ConnectTo is not used
<marcan>
maybe DCP just has its *own* dpmux functionality?
<marcan>
and macos just doesn't use it?
<marcan>
(maybe we should!)
<sven>
hah :D
<sven>
which MMIO can dcp access?
<marcan>
it does have a bunch built in... need to check the DART
<sven>
maybe it'll just try to write to the same crossbar regs
<marcan>
yup, entirely possible
<sven>
the xnu function which sets up the crossbar is called connect and/or bringConnectionUp iirc
<_jannau_>
I don't rememeber to what they map, one is afaik pmgr
<DmitrySharshakov[m]>
povik: Are the I2C buses amps sit on left exposed to userspace via `/dev/i2c-*`? I guess you might have to probe `i2c-dev` to find that out.
<DmitrySharshakov[m]>
Those should be hidden to ensure nobody like lm-sensors detection accidentally taps them
<DmitrySharshakov[m]>
Probably only I2C buses which should remain visible are DCP ones (when supported)
<povik>
not sure
<DmitrySharshakov[m]>
Idk if i2c-dev can be made to avoid some buses in its current condition
<_jannau_>
we don't have direct access to DDC/CI
<DmitrySharshakov[m]>
Is there any way to use ddc/ci via firmware?
e1eph4nt has quit [Ping timeout: 480 seconds]
<DmitrySharshakov[m]>
Does macOS support DDC/CI on Apple Silicon machines?
e1eph4nt has joined #asahi-dev
AlbertoBasaglia[m] is now known as albertobasaglia[m]
<marcan>
sven: try experiments/dcpext_iboot.py
<marcan>
it doesn't do anything for me, but maybe it will for you when you actually set up the xbar
<marcan>
also fetch again, I had a HV regression that wasn't committed yet
<sven>
NameError: name 'DEFAULT_ARCH' is not defined <-- I think you forgot to push some changes
<sven>
and/or this breaks on macos only
<j`ey>
yeah povik hit that too
<j`ey>
sven: (dumb) question, what does DPIN0 and DPIN1 actually mean?
<sven>
probably display port input 0/1 for the usb4 tunelling mess
<j`ey>
but isn't display port.. output?
<sven>
input from ATC's point of view
<j`ey>
ah
<sven>
looks like i'm still missing some initialization stuff for the dpphy fwiw
<povik>
the last PR i opened with a commit stash has the DEFAULT_ARCH fix
<povik>
ha! knew there was the way to get the PR merged :p
<povik>
s/there/that
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
<povik>
marcan: if you get a moment please also review the 9p export
<marcan>
lol I just realized EPIC is EndpointInterfaceClient
<sven>
:D
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Remote host closed the connection]
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
<jannau>
povik: amp-dcblocker-config seems to be a m2 thing. now I fear that apple uses not only per SoC kernel/driver binaries but also per SoC source code
<povik>
:D
<sven>
wouldn’t surprise me :D
<DmitrySharshakov[m]>
Maybe they got tired of hardcoding things and started moving more to DT? I really hope code tries to search for prefs in DT and if not found applies the hardcoded default
<shorne>
Hello, I am working on installing my own kernel on the m2 air (I am a kernel developer). In grub I don't get a keyboard to select the appropriate kernel
<shorne>
I read that this is fixed in the latest u-boot
<jannau>
why would u-boot search for dtbs after it probed usb?
<jannau>
shorne: u-boot has to use the dtb passed along by m1n1
<shorne>
jannau: yes, it seems that failed
<shorne>
j`ey: thanks, maybe its good to have this script referenced in the readme's
<jannau>
u-boot shouldn't be able to probe usb without dtb passed along from m1n1
<j`ey>
shorne: what distro are you using?
<shorne>
jannau: I am just remembering the error it showed, its not in front of me right now after I rebooted
<shorne>
j`ey: arch
<j`ey>
shorne: then why couldnt you just update the package?
gladiac is now known as Guest1596
gladiac has joined #asahi-dev
<shorne>
j`ey: right, I could do that, at first I didn't think it was packaged yet because the only info I found was a tweet saying its fixed on a dev branch
<shorne>
now I see its in PKGBUILDs so right, I can just use that
<shorne>
Aha, I was understanding asahi-dev repo as the git repo !_!
<shorne>
I am not too familiar with arch yet
Guest1596 has quit [Ping timeout: 480 seconds]
<marcan>
sven: figured out how to enable a bunch of extra DCP debug, not sure if it's useful though (see latest commits)
<sven>
I’m reasonably sure I mess up the atcphy/dpphy stuff somewhere fwiw
<sven>
something is missing to establish the connection
e1eph4nt has joined #asahi-dev
<pabloscloud[m]>
So.. How far is the graphic driver? 😃
<pabloscloud[m]>
I‘m super excited about running Linux on my Mac and it already worked pretty well a months ago except videos
e1eph4nt has quit [Ping timeout: 480 seconds]
<marcan>
sven: also made displayRequest() not hang, so that triggers that power up message in case that helps
<marcan>
going to sleep
<marcan>
pabloscloud[m]: asking isn't going to make it go any faster, and asking in the channel where developers are trying to work on things *definitely* isn't going to make it go faster ;)
<sven>
goodnight! I’m gonna give it another try later
<sven>
just adopt my policy that ever question about $x progress delays $x by a month :>
e1eph4nt has joined #asahi-dev
<maz>
sven: make it exponential!
<sven>
ohhh…. that’s even better!
<shorne>
j`ey: ok, now I have the asahi-dev arch package repo enabled, I have keyboard and can boot my own kernels
bluetail21 has quit [Read error: Connection reset by peer]
bluetail21 has joined #asahi-dev
jakebot602 has quit [Remote host closed the connection]
jakebot602 has joined #asahi-dev
<pabloscloud[m]>
<marcan> "pabloscloud: asking isn't..." <- So what? Didn’t want to make it faster
<jannau>
is up to 10Gbit/s a valid claim for the usb xhci with "pci 0000:04:00.0: 7.876 Gb/s available PCIe bandwidth, limited by 8.0 GT/s PCIe x1 link at 0000:00:03.0 (capable of 15.752 Gb/s with 8.0 GT/s PCIe x2 link"
bluetail21 has quit [Read error: Connection reset by peer]
bluetail21 has joined #asahi-dev
bpye has quit [Quit: Ping timeout (120 seconds)]
bpye has joined #asahi-dev
<opticron>
pabloscloud[m], he means that bothering the devs for status only slows them down, this is the wrong channel/room for that question anyway and pollutes discussion about development issues
<pabloscloud[m]>
Didn’t know there where other rooms
<pabloscloud[m]>
s/where/were/
<jannau>
893.54 MB/sec
<jannau>
vs. 785.06 MB/sec on one of the usb-a ports of the mac studio
bluetail215 has joined #asahi-dev
bluetail21 has quit [Read error: Connection reset by peer]
e1eph4nt has quit [Ping timeout: 480 seconds]
<sven>
marcan: the debug stuff is nice, still stuck at "waiting for HPD" though. I'll have to look again and see if I missed any dpphy/atcphy init
e1eph4nt has joined #asahi-dev
hays has quit [Remote host closed the connection]
derzahl has joined #asahi-dev
gladiac has quit [Quit: k thx bye]
hays has joined #asahi-dev
<povik>
jannau: i just remembered seeing that one of MCA or ADMAC had surprisingly different driver kexts for t8103 and t6000 (judging on strings), so that furthers the suspicion
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
bluetail215 has quit [Read error: Connection reset by peer]
bluetail215 has joined #asahi-dev
bluetail215 has quit []
bluetail215 has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
bluetail215 has quit []
bluetail215 has joined #asahi-dev
bluetail215 has quit []
bluetail215 has joined #asahi-dev
e1eph4nt has joined #asahi-dev
bluetail215 has quit []
bluetail215 has joined #asahi-dev
bluetail215 has quit [Ping timeout: 480 seconds]
<shorne>
hi, as I mentioned before I am looking to help with getting s2idle working. Probably nothing new here, but I compile the kernel with CONFIG_SUSPEND on and played with "mem" suspend.
<shorne>
As other reported it doesn't work, but I see now exactly where
<tpw_rules>
i think it doesn't work because stuff like the hard disk won't wake back up properly
<shorne>
brcmfmac 0000:01:00.0: brcmf_pcie_pm_enter_D3: Timeout on response for entering D3 substate
<tpw_rules>
and wifi
<shorne>
the dirver sends a request to enter D3 in its .suspend callback
<shorne>
but the wifi device doesnt respond
<shorne>
I guess we have to reverse engineer the protocol that apple uses to suspend the device
<shorne>
I'll search if there is any documentation on this already
<shorne>
otherwise ill start looking in m1n1
<shorne>
need to go to bed
<jannau>
shorne: I don't think so. marcan is planning to use the PCI tracer he started yesterday to see what macos is doing
<jannau>
for wifi
bluetail215 has joined #asahi-dev
StupidYui has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
Manouchehri_ has quit []
e1eph4nt has joined #asahi-dev
bluetail215 has quit []
bluetail215 has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
jluthra_ has quit [Remote host closed the connection]