ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
cuolin^ has quit [Ping timeout: 480 seconds]
dmmcf has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
riker77_ has joined #asahi-dev
riker77 has quit [Ping timeout: 480 seconds]
riker77_ is now known as riker77
cuolin^ has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
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
<Dcow[m]> https://matrix.to/#/#asahi:fedora.im
<Dcow[m]> I think it's a best to discuss in there
<DmitrySharshakov[m]> Sure, thanks
e1eph4nt has joined #asahi-dev
<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]
Swiftloke has joined #asahi-dev
sven has quit [Quit: ZNC 1.8.2 - https://znc.in]
sven has joined #asahi-dev
jakebot60 has quit [Quit: The Lounge - https://thelounge.chat]
jakebot602 has joined #asahi-dev
<marcan> sven: not really, other than maybe it expects some init we don't do, or it's outright disabled for dcpext?
<marcan> how does it fail?
<sven> Doesn’t get past the “waiting for hpd” thing, I’m not convinced I have the correct dpphy bringup though
<sven> maybe I should just update this Mac mini and try the real protocol though just to be sure
uniq has quit [Quit: Textual IRC Client: www.textualapp.com]
<marcan> oh then yeah, no hpd just means nothing connected to the output
<marcan> so that's probably your fault :>
<marcan> the thing is, there are DCP EPIC protocols for the DP stuff that may be required for dcpext too
<marcan> since the firmware knows about atcphy/etc
<marcan> so maybe there are commands to send there (those aren't part of the main dcpep thing)
<marcan> see dcpav.py, but there's more missing
e1eph4nt has quit [Ping timeout: 480 seconds]
<marcan> for DP stuff there's an object with stuff like SetLinkRate/SetLaneCount/SetDriveSettings
<marcan> and another one with stuff like RetrainLink/GetSinkCount
<marcan> and another DP-related one has SetPower too
<marcan> and there is an AppleDCPDPTXRemotePort that has DisplayRequest/DisplayRelease/ConnectTo/ValidateConnection
<marcan> I wonder if that's the one you need
<marcan> connectTo references this string: "core%u -> %u,%u (ATC%u::%s) supportsHPD=%u: ret=0x%08x"
<marcan> sven: ^
<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
<sven> doesn't seem to contain the xbar
<_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
gladiac has joined #asahi-dev
Race has quit [Ping timeout: 480 seconds]
<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
<shorne> so I installed the latest u-boot (as I understand), is latest uboot this one? https://github.com/AsahiLinux/u-boot/commits/asahi (0c9bd6e64020c95731caacf787d94d70daec3f16)
<shorne> ah, asahi-releng, I didn't find that reference
<shorne> I saw that, didn't make the link, ok let me try that on
<shorne> j`ey: thank you
<shorne> j`ey: thanks, I see and the tag and the branch are the same commit, I didnt know of the PKGBUILDs repo yet
<shorne> here it goes
e1eph4nt has quit [Ping timeout: 480 seconds]
<shorne> well that didnt work, after probing the USB devices u-boot fails to find the dtb's
<shorne> maybe I packaged it incorrectly
<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
<j`ey> shorne: packages like uboot/kernel go into the asahi-dev repo first: https://cdn.asahilinux.org/aarch64/asahi-dev/ and then get moved into the main repo after testing
clararussel[m] has joined #asahi-dev
<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
<shorne> thanks
<jannau> shorne: should be in the asahi pkg repo as well since https://twitter.com/AsahiLinux/status/1560955501831417856
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]
jluthra_ has joined #asahi-dev