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
<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
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?
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
<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