marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
dgb_ has quit [Quit: WeeChat 2.7.1]
dgb has joined #asahi
bpye has quit [Ping timeout: 240 seconds]
bpye has joined #asahi
brinly has quit [Ping timeout: 258 seconds]
stblassitude has quit [Ping timeout: 245 seconds]
kido has quit [Ping timeout: 258 seconds]
stblassitude has joined #asahi
kido has joined #asahi
brinly has joined #asahi
inglor has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
phiologe has quit [Ping timeout: 250 seconds]
phiologe has joined #asahi
inglor has joined #asahi
<marcan> kettenis_: just the code to apply reg/mask/val type stuff? that's fairly obvious; I don't know if we'll end up using the same format, but I don't see that particular bit being a problem
<marcan> oh you mean the preloader code that pulls the fuses
<delroth> marcan: do you not receive Konrad Dybcio's emails btw? :P
<marcan> delroth: I don't have anything by that name
<delroth> that would explain it
qncfj has joined #asahi
<marcan> huh
bgianf has quit [Quit: Lost terminal]
<marcan> oh
<marcan> he replied to list, not reply all
<delroth> yeah I was just figuring out the same thing
<marcan> is... that a thing?
<marcan> I normally expect replies to go to me :p
<delroth> that seems like a fair expectation
<mjg59> Communities vary on that a lot, but Cc:ing the poster is normal on kernel-related lists
<marcan> yeah; if the ML spoofs reply-to then I expect on-list replies, but that isn't the case here
<marcan> either way, I can fix this in a sieve rule, probably
<Shiz> my experience with MLs is that it's common to indicate you're not subscribed so that posters can CC you explicitly
<marcan> I think that's the case on MLs that do that reply-to munging
zkrx has quit [Ping timeout: 240 seconds]
<marcan> https://mrcn.st/p/QC01QNKq that should do it
zkrx has joined #asahi
marvin24 has quit [Ping timeout: 245 seconds]
marvin24 has joined #asahi
odmir has quit [Remote host closed the connection]
bpye has quit [Ping timeout: 240 seconds]
bpye has joined #asahi
Nazral has quit [Ping timeout: 252 seconds]
Nazral has joined #asahi
mxw39 has quit [Quit: Konversation terminated!]
mxw39 has joined #asahi
mxw39 has quit [Remote host closed the connection]
mxw39 has joined #asahi
mxw39 has quit [Remote host closed the connection]
mxw39 has joined #asahi
mxw39 has quit [Remote host closed the connection]
mxw39 has joined #asahi
mxw39 has quit [Quit: Konversation terminated!]
mxw39 has joined #asahi
JaehyukLee[m] has joined #asahi
<JaehyukLee[m]> Hi, Is it possible to use PMU in m1 machine? I tried to enable user access on the PMU with msr pmuserenr_el0 instruction, but system hangs right away
JaehyukLee[m] is now known as Jaehyuk[m]
<marcan> Jaehyuk[m]: M1 implements apple-proprietary PMCs, not the standard ARM PMU, unfortunatelty
<marcan> *unfortunately
<Jaehyuk[m]> marcan: Thank for letting me know that. Does the asahi Linux have reverse-engineered PMU supports?
<Jaehyuk[m]> or is there any on-going project to reverse engineer their PMU?
<marcan> the details are still fairly unknown
modwizcode has quit [Remote host closed the connection]
<Jaehyuk[m]> marcan: Wow.. I appreciate it! how those performance counters have been reverse engineered..?
<marcan> that info is actually from the XNU source code
<marcan> with some details added by me by poking around that were missing
<marcan> (e.g. some stuff about counters 8/9)
mxw39 has quit [Quit: Konversation terminated!]
mxw39 has joined #asahi
mxw39 has quit [Remote host closed the connection]
<marcan> kettenis_: re those fuse tunables, it's just reading some fields and poking them into registers, right? I think it's fine to use the table corellium has for that as a reference
mxw39 has joined #asahi
<Jaehyuk[m]> marcan: Ah.. good to know that!
<amonakov> Jaehyuk[m]: Dougal Johnson was using the counters to study the microarchitecture: https://dougallj.github.io/applecpu/firestorm.html
<Jaehyuk[m]> I appreciate it.
<Jaehyuk[m]> Ah, were those result retrieved on the asahi linux ?
<amonakov> I believe he did the work on OS X
<Jaehyuk[m]> yes yes ("/System/Library/PrivateFrameworks/kperf.framework/Versions/A/kperf" in the source code)
<Jaehyuk[m]> This is a very dumb question. I didn't have a chance to install ashai linux yet and playing with the corellium's linux for several months. Does ashai linux also support booting from nvme?
<Jaehyuk[m]> cause it seems that it requires another mac for terminal or arduino
<marcan> nvme is coming soon
mxw39 has quit [Remote host closed the connection]
<marcan> we've been working on defining the base support, bindings, etc and upstreaming that first; expect a lot of drivers to follow very quickly now that that's almost done :)
mxw39 has joined #asahi
<Jaehyuk[m]> I see.. this is also very dumb question, why asahi linux started to implement its linux support from the scratch instead of adopting the corellium's linux ? Is it because to provide linux-like environment, booting from grub?
<Jaehyuk[m]> Sorry to bother you
mxw39 has quit [Client Quit]
mxw39 has joined #asahi
<marcan> our goal is to upstream support for the M1 into the official kernel, but corellium doesn't seem to be interested in that. they haven't replied to any of the upstreaming e-mail threads.
<marcan> a lot of their code doesn't meet upstreaming standards, and I also don't know how it was developed; I would like some answers about their development methodology before using any of it directly, but all we've gotten so far is silence
<marcan> since they are not interacting with the community, and we cannot get any feedback on their code, it seems best to just work on it from scratch with an upstreaming mentality
<Jaehyuk[m]> I totally understand now. Thanks a lot :D
qncfj has quit [Quit: WeeChat 3.0]
jeffmiw_ has joined #asahi
jeffmiw_ has quit [Ping timeout: 260 seconds]
Necrosporus has quit [Ping timeout: 240 seconds]
bisko has joined #asahi
klaus has joined #asahi
furkan has quit [Ping timeout: 260 seconds]
raster has joined #asahi
furkan has joined #asahi
flying_sausages has quit [Ping timeout: 260 seconds]
furkan has quit [Ping timeout: 240 seconds]
odmir has joined #asahi
furkan has joined #asahi
odmir has quit [Ping timeout: 240 seconds]
jeffmiw_ has joined #asahi
jeffmiw_ has quit [Client Quit]
ephe_meral has joined #asahi
ephe_meral1 has joined #asahi
ephe_meral has quit [Ping timeout: 268 seconds]
ephe_meral1 has quit [Ping timeout: 260 seconds]
furkan has quit [Ping timeout: 240 seconds]
ephe_meral1 has joined #asahi
furkan has joined #asahi
flying_sausages has joined #asahi
furkan has quit [Ping timeout: 268 seconds]
vimal has joined #asahi
furkan has joined #asahi
HannaM has joined #asahi
_andy_t_ has joined #asahi
Necrosporus has joined #asahi
rjeffman has joined #asahi
odmir has joined #asahi
odmir has quit [Ping timeout: 240 seconds]
odmir has joined #asahi
<kettenis_> marcan: cool; i'll probably come up with a somewhat different way to express what bits should be taken and where they should be deposited
<kettenis_> in order to apply the PCIe PHY I need to enable some clocks and take it out of reset
<kettenis_> so the knowledge about which bits to poke and check comes from the corellium codebase as well
<kettenis_> (but no code got copied in the process)
<marcan> kettenis_: this is for m1n1, right?
<marcan> and yeah, that's basically fine; I'm not too worried about general poke-bits stuff and the clocks (which sven is also looking at) seem pretty simple afaik?
<marcan> it's nontrivial driver logic where I start worrying
<marcan> going to look at PRs now :)
<kettenis_> marcan: yes, I'm more or less writing the code for m1n1 that is needed to make the pcie "tunables" stick
<marcan> right
odmir has quit [Remote host closed the connection]
<kettenis_> there are some per-port "tunables" that don't survive a PCI Express reset
<kettenis_> these are basically PCI config space changes on the bridge devices corresponding to the three ports
choozy has joined #asahi
<marcan> sounds like we're going to have to put at least *some* tunables in the DT then
<marcan> though those aren't the fuse ones, right?
<kettenis_> right
<marcan> so there is also the option of just embedding them in the kernel driver, which is how most other drivers do this, though obviously that is less flexible
<kettenis_> so the tunables that start with "apcie" in the ADT can be applied in a fairly straightforward manner
<kettenis_> the ones that start with "pcie" are the ones that tweak config space and get undone by a PCI Express reset
<kettenis_> still need to figure out what happens to the "apcie" ones if I gate/ungate the clocks
<marcan> robher: how do you want to handle this kind of thing? tl;dr Apple passes lists of register addr/mask/values in their devicetree. so far the ones we care about seem to be static for any given device, not sure about if they change between devices using the same soc (hopefully not? should check that)
<marcan> I'm not sure if this is common; I know nvidia used to do hideous stuff along these lines in their L4T tree
<marcan> one issue is that we don't know what most of these registers are, so we can't come up with nice symbolic names for them
<marcan> though for config space, some of it might be totally bog standard stuff we can reverse engineer and handle at a high level sanely
<kettenis_> some of the modified registers are in standard pcie extended capabilities
odmir has joined #asahi
odmir has quit [Remote host closed the connection]
odmir has joined #asahi
odmir has quit [Ping timeout: 260 seconds]
odmir has joined #asahi
odmir has quit [Ping timeout: 240 seconds]
odmir has joined #asahi
<svenpeter> Marcan: yeah, clocks are rather simple. Tl;dr: most devices have a clock gate which can be enabled by flipping some bits and some of them additional clocks with a frequency (like uart or iic).
<kettenis_> svenpeter: can you actually set the frequency of those clocks?
<svenpeter> The ones with the frequency are preconfigured by iBoot and we can just pretend they are static for now. From some highly advanced strings reverse engineering I’ve done they might be mux clocks.
<kettenis_> good, as far as I can determine all the other PCIe tunables stick even if I disable the clocks
<svenpeter> Nice! The same is true for the dart tunables at least. Though I’m not sure they are even required
<marcan> kettenis_: if you have time, you can see if the ones that don't stick can be described in terms of standard caps, and what they do exactly
<marcan> it might be something completely bog standard or representable at a higher level, that we can turn into sensible driver logic
<marcan> and drop that tunable entirely
<marcan> I get the feeling Apple is using this whole "tunables" business, in part, as a lazy "eh, this is the init sequence, and we can't be arsed to put it in xnu"
<marcan> not actual "magic" stuff
<marcan> things that do very specific, sensible things, that we might even want to configure or drive at a higher level
<marcan> of course some stuff will be magic (e.g. almost certainly the fused bits), anything touching the PHY especially
<marcan> but I bet for stuff above that level we can, with enough effort, work out what's going on
<marcan> since m1n1 gets the tunables from iBoot anyway, we can just apply them; but I'll be very happy if whatever we need to pass on to the kernel is understood more properly
<marcan> trying to prevent a situation where we end up passing tunable nonsense in the DT that then in the future can go away as we understand things better, if at all possible
<marcan> heck, for all I know some of this stuff might already have sensible DT bindings in linux; configuring root port settings sounds like something a lot of socs would need
<marcan> and e.g. I would *love* to understand anything related to axi, memory transactions, etc since I bet we might end up having to fix bugs by tweaking stuff there
Fanfwe has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
Fanfwe has joined #asahi
<kettenis_> I'll take a closer look later, but it seems they're knocking out some bits related to link power management
<kettenis_> smells like they're workarounds for silicon bugs that they hope to fix in a future respin
bisko has quit [Quit: Textual IRC Client: www.textualapp.com]
Fanfwe has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
Fanfwe has joined #asahi
_whitelogger has joined #asahi
titanous has left #asahi [#asahi]
ephe_meral1 has quit [Ping timeout: 265 seconds]
choozy has quit [Read error: Connection reset by peer]
choozy has joined #asahi
Fanfwe has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
Fanfwe has joined #asahi
Fanfwe has quit [Client Quit]
Fanfwe has joined #asahi
<kettenis_> documented the PCIe config space tunables at https://github.com/AsahiLinux/docs/wiki/HW:APCIe#tunables
choozy has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
frode_0xa has joined #asahi
jeffmiw_ has joined #asahi
jeffmiw_ has quit [Remote host closed the connection]
VinDuv has joined #asahi
jeffmiw_ has joined #asahi
vlixa has quit [Remote host closed the connection]
vlixa has joined #asahi
VinDuv has quit [Quit: Leaving.]
Bublik has quit [Ping timeout: 260 seconds]
Bublik has joined #asahi
jeffmiw_ has quit [Remote host closed the connection]
luca020400 has quit [Quit: WeeChat 3.1]
luca020400 has joined #asahi
luca020400 has quit [Read error: Connection reset by peer]
luca020400 has joined #asahi
PendulumSwinger has quit [Quit: Ping timeout (120 seconds)]
PendulumSwinger has joined #asahi
Fanfwe has quit [Ping timeout: 265 seconds]
Fanfwe has joined #asahi
milek7 has quit [Remote host closed the connection]
milek7 has joined #asahi
luca020400 has quit [Remote host closed the connection]
luca020400 has joined #asahi
jeffmiw_ has joined #asahi
jeffmiw_ has quit [Ping timeout: 265 seconds]