ChanServ changed the topic of #asahi-re to: Asahi Linux: porting Linux to Apple Silicon macs | Hardware / boot process / firmware interface reverse engineering | WARNING: this channel (only) may contain binary reverse engineering discussion | RE policy: https://alx.sh/re (MANDATORY READ) | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-re
al3xtjames has quit [Quit: Ping timeout (120 seconds)]
al3xtjames has joined #asahi-re
PhilippvK has joined #asahi-re
phiologe has quit [Ping timeout: 480 seconds]
quarkyalice has quit [Remote host closed the connection]
quarkyalice has joined #asahi-re
quarkyalice has quit [Remote host closed the connection]
quarkyalice has joined #asahi-re
<marcan>
sven: yeah, I was thinking that DCP is probably the only case where those drivers are so broken out in macos, but I think for linux those things tend to be all monolithic
<marcan>
so we can probably just drive them all from a single DCP driver eventually
yuyichao has joined #asahi-re
quarkyalice_ has joined #asahi-re
quarkyalice has quit [Ping timeout: 480 seconds]
quarkyalice has joined #asahi-re
besmirich[m] has joined #asahi-re
<sven>
marcan: yeah, so if we can really just handle every single co-processor with a single driver i think that shared rtkit library you suggested makes sense
<marcan>
yeah, tbh I don't see modularity really helping us here
<marcan>
after all whoever wants to run these things will need the whole driver anyway
<marcan>
and if the thing crashes the whole thing crashes
<sven>
yeah
<marcan>
trying to split it up into modules... would just add overhead for no reason
<sven>
i briefly looked into remoteproc but that doesn't fit all that well either
<marcan>
yeah, different story
<sven>
yeah
<marcan>
I took a good look at mailbox the other day and I don't like that we can't use the channel concept, but given this situation, it's not worth making changes to that
<sven>
so just a simple mailbox driver + rtkit shared library sounds good then
<marcan>
let's just treat it as a single-channel mailbox
<marcan>
and deal with the endpoints on our rtkit stuff
<marcan>
the rtkit lib would of course be a module to be shared by all the drivers
<sven>
yeah
<sven>
the whole channel concepts really seems to be more about a single mailbox block having multiple FIFOs
<sven>
which... we don't
<marcan>
yeah, exactly
<marcan>
though it could be adapted to ours by adding a mode to mailbox where all channels share a busy status
<marcan>
but... not worth it, I think
<marcan>
given we're building monolithic drivers anyway
<sven>
yeah. the core needs a small change anyway unless we want to wait for an interrupt for every single message we sent
<sven>
but that's a small thing
<marcan>
yeah that too, the queuing
<marcan>
it would need a flag to poll after a send
<marcan>
just once
<marcan>
so that it can keep sending
<marcan>
but it might not matter in practice for now
<marcan>
so we can also just defer that to whenever we run into perf issues
<marcan>
oh, also: the DT bindings need some thought. I want to make sure that e.g. if we decide the mailbox framework sucks one day, that we don't run into issues with the bindings
<marcan>
whatever we decide one needs to be fairly future-proof
<sven>
yeah, i have two variants that i implemented: one just uses the poll mode as-as. the other one convinces it to keep sending unless it gets EBUSY and request the irq to continue then
<marcan>
*on
<marcan>
yeah
<marcan>
ok, I'm going to stream a bit today, what was on the nobody's doing it list? i2c and pinctrl was it?
<sven>
clocks, i2c. i think j_ey did some work on gpio/pinctrl but i dunno how far along he is
<marcan>
ah, right, clocks
<marcan>
sounds good
<marcan>
we never figured out the clock dependency stuff, right? I guess I'll just do $something and then see what upstream says
<marcan>
ah that was the instance per clock model, right?
<marcan>
and yeah
<sven>
that was a single clock controller with a clocks property that can reference the controller itself
<sven>
which the maintainers would probably hate and which isn't enough anyway because the two parents thing
<sven>
+of
<marcan>
yeah
<marcan>
I think, realistically, this needs to be a DT structure
<marcan>
with subnodes for clocks
<marcan>
one way or another
<marcan>
I'll poke around
<sven>
yeah
<sven>
marcan: pmgr.c is missing the second parent fwiw. i think it was just after the first parent in the structure at the top
<marcan>
ack
<marcan>
it's max 2?
<sven>
haven't seen anything with more than 2
<marcan>
ok
<sven>
there's still 2 unknown bytes so it could be three i guess
x56 has quit [Quit: Ծ-Ծ]
x56 has joined #asahi-re
chadmed has quit [Remote host closed the connection]
chadmed has joined #asahi-re
chadmed has quit [Remote host closed the connection]
chadmed has joined #asahi-re
afwolfe has joined #asahi-re
afwolfe has quit []
yuyichao has quit [Ping timeout: 480 seconds]
jbowen has joined #asahi-re
chadmed has quit [Ping timeout: 480 seconds]
jeffmiw has joined #asahi-re
chadmed has joined #asahi-re
phiologe has joined #asahi-re
PhilippvK has quit [Ping timeout: 480 seconds]
jbowen has quit [Read error: Connection reset by peer]
jbowen has joined #asahi-re
jeffmiw has quit [Ping timeout: 480 seconds]
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #asahi-re
jbowen has quit [Ping timeout: 480 seconds]
jbowen has joined #asahi-re
jeffmiw has joined #asahi-re
shaman_br[m] has joined #asahi-re
jbowen has quit [Ping timeout: 480 seconds]
jbowen has joined #asahi-re
yuyichao has joined #asahi-re
yuyichao has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi-re
PhilippvK has joined #asahi-re
phiologe has quit [Ping timeout: 480 seconds]
jbowen has quit [Ping timeout: 480 seconds]
j_ey has joined #asahi-re
<alyssa>
j_ey: the "S" in "SIO" is for "Smart"
<j_ey>
actually?
<alyssa>
Yes.
<j_ey>
so what does it actually handle? (the sio asc)
<alyssa>
Dunno
<alyssa>
I just like expanding acronyms
<jeffmiw>
is this expansion of the acronym based on some reverse eng ?
<alyssa>
i'll leave that one up to your imagination
<jeffmiw>
:)
<alyssa>
j_ey: It might just be the DMA controller...?
<alyssa>
well, a DMA controller
<j_ey>
it does have a dma controller subnode..
<jeffmiw>
this is what I was thinking of, the combination of sio & dart-sio to do some dma stuff from spi .... but no real facts I can use to confirm this speculation ...
<j_ey>
trace macOS a bit?
<jeffmiw>
this is what I'm doing to try to understand and found those sio / dart-sio acesses, thus my initial questions if anyone knows anything about them
<jeffmiw>
I'll continue try to figure it out
<sven>
uh
<sven>
see #asahi. it at least maps the aes engine
jbowen has joined #asahi-re
<jeffmiw>
sven: thx. what it seems to me is that the kbd/spi patches from amw including Corellium patches are not using the same mode of spi that macos is using, but I can be mistaken.
<sven>
dma doesn't make much sense for a keyboard though
<sven>
maybe for the nor flash, but even that one is quite small and probably not read/written often
jbowen has quit [Quit: leaving]
<sven>
but anyway, if they use DMA for SPI for some reason and if that co-processor is involved you will have to reverse engineer its protocol
<jeffmiw>
touchpad ? yeah re. eng. is needed then. I will continue dig into it.
<sven>
it's rtkit, so you could try to use the asctracer (i think it's called like that) and see what messages are exchanged
<sven>
and if you trace the DART mappings as well you should be able to see what data it exhanges
<j_ey>
you'll have to figure out extra messages it may do, whats in the asctracer currently is only what markan figured out for dcp
<sven>
it should handle syslog and the rtkit bootstrap stuff though
<j_ey>
heh, the thing that marcan fixed today was one of the things I hit, syslog with the buffer size c39fe2fbdea0a9eaf5c32b519d674820b46509a6
jeffmiw has quit [Ping timeout: 480 seconds]
<alyssa>
sven: speaking of aes, I wonder how much prior art there are for things like aes and jpeg which have s5l-era compatibles in the ADT
<sven>
aes is simple enough, i reversed that one back in match or so
<alyssa>
ooh
<sven>
i was hoping to use it to understand DART better but couldn't get it to work and gave up after 30 minutes
<sven>
or, well, i could only get it work in bypass mode
<alyssa>
er?
<sven>
there's a DAPF behind that DART that needs to be configured
<alyssa>
DAPF?
<sven>
no idea what that is
<sven>
i just know that the AES DART wasn't able to even read the pagetable
<alyssa>
also, any idea what NCO is?
<sven>
non-comissioned officer? :P
<alyssa>
I meant in the adt :-p
<alyssa>
compatible = [nco,t8101, nco,s5l8960x]
<alyssa>
I guess power management related
<sven>
AppleS5L8960XNCOFrequencyFunction
<alyssa>
How enlightening :-p
* alyssa
wonders if jpeg/scalar are used at all in macOS or are just legacy from old iphones
<marcan>
SIO apparently can handle a bunch of IO paths including SPI/UART/etc, but it looks generic
<marcan>
i.e. we don't *have* to use it
blazra[m] has joined #asahi-re
<marcan>
< sven> i just know that the AES DART wasn't able to even read the pagetable <- that matches the 1:1 memory map entry in the DAPF I saw, with special flags