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 [Read error: Connection reset by peer]
al3xtjames has joined #asahi-re
amw has joined #asahi-re
chadmed has quit [Remote host closed the connection]
yuyichao has quit [Ping timeout: 480 seconds]
chadmed has joined #asahi-re
yuyichao has joined #asahi-re
PhilippvK has joined #asahi-re
phiologe has quit [Ping timeout: 480 seconds]
<rqou_> anybody have any guesses what these prores parameters might control? https://github.com/rqou/m1n1/blob/prores/proxyclient/experiments/prores.py#L621
<rqou_> in other news, i have an experiment that's able to drive the prores encoder usefully
nicolas17 has quit [Quit: Konversation terminated!]
<Jamie[m]1> ayy
<rqou_> in addition to the magic quality parameters, i do still have a concern of "how the heck does the hardware know what size of descriptor it should be reading?"
<rqou_> i asuume _that_ might be related to some of the magic flags that are also not understood
<rqou_> does anybody know what IOSurface::getTileHeaderRegionOffsetOfPlane does?
<rqou_> is this related to AGX compression or is this a different way to make data be tiled?
MajorBiscuit has joined #asahi-re
Major_Biscuit has joined #asahi-re
MajorBiscuit has quit [Ping timeout: 480 seconds]
jaalsa has joined #asahi-re
<sven> amarioguy: finally found the slightly better sep trace i worked on a while ago. it's probably broken though https://f.svpe.de/d48b3719f56e413e94ca40a6e9cbc8636577695c66054ef44093270998999449_trace_sep.py
the_lanetly_052___ has quit [Remote host closed the connection]
the_lanetly_052___ has joined #asahi-re
chadmed has quit [Read error: Connection reset by peer]
the_lanetly_052___ has quit [Ping timeout: 480 seconds]
chadmed has joined #asahi-re
caef^ has quit [Remote host closed the connection]
bisko has joined #asahi-re
yuyichao has quit [Ping timeout: 480 seconds]
atsalyuk has joined #asahi-re
yuyichao has joined #asahi-re
atsalyuk has quit [Ping timeout: 480 seconds]
ave3 has quit [Remote host closed the connection]
linuxgemini9 has quit [Remote host closed the connection]
linuxgemini9 has joined #asahi-re
ave3 has joined #asahi-re
atsalyuk has joined #asahi-re
doggkruse has joined #asahi-re
linuxgemini95 has joined #asahi-re
ave36 has joined #asahi-re
linuxgemini9 has quit [Ping timeout: 480 seconds]
ave3 has quit [Ping timeout: 480 seconds]
nicolas17 has joined #asahi-re
doggkruse has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
doggkruse has joined #asahi-re
atsalyuk has quit [Remote host closed the connection]
atsalyuk has joined #asahi-re
sikkileo[m] is now known as sikkiladho[m]
Major_Biscuit has quit [Ping timeout: 480 seconds]
<rqou_> sven: re DART "uncacheable": i'm going off of the DWARF symbols in the KDK KernelSupport object files which contain a DW_TAG_typedef for "tXXXXdart_l3tte_t"
<rqou_> which for t6000 and t8110 indeed look the same, with bits 0-3 being valid, uncacheable, wrprot, rdprot
<rqou_> i'm not sure how i would go about testing whether device accesses are bypassing cache though
<rqou_> t8020 also appears to have wrprot at bit7 and rdprot at bit8 according to the symbols
<sven> hrm, so write and read protection also moved around compared to t8103
<sven> yeah
<sven> do you have some device for which you can easily trigger a read from a page and time it?
<sven> if it bypasses the cache that should be slower
<rqou_> i do know of such devices (jpeg, prores), but i don't know how to get any useful timings
<rqou_> i'm driving them with m1n1 python scripts and polling for the done bit
<sven> hrm, let me check if I ever pushed my code to drive that AES engine
<sven> it should be behind a t6000 dart at least
<rqou_> also, from the symbols, t6000 doesn't have the error disable bits that t8020 has in the TCR (none of which are in m1n1)
<sven> i wasn't aware there are any error disable bits
<sven> I figured out most of DART by poking registers and observing what happens, we didn't have the HV back then :D
<sven> http://f.svpe.de/70fb5357bea78c2e50f0017f563907ebe775cd731861d37751346a1eb8ad61c9_aes.py looks like I didn't find the ready bit in that aes engine :/
<rqou_> the typedef in the KDK for "dart_blk_sid_config_v8_t" has a bunch of disable bits, e.g. "disable_ttbr_invalid_err" "disable_ste_invalid_error" etc.
<sven> never looked at the KDK
<rqou_> there's also bypass_addr_39_32 (and bypass_addr_41_32 for t6000) in the TCR
<rqou_> but i don't quite understand how bypass mode works (and i'm not sure t8110 has it)
<sven> if you set that bypass enable bit in TCR it just passes through all DMA transactions
<sven> I guess you can also give them an offset then? dunno
<rqou_> isn't the iova space smaller than the physical address space?
<sven> yes
<sven> but that limitation only applies in translated mode on t8103 at least
<rqou_> oh ok
<sven> if you e.g. enable bypass for dwc3 you can just pass the phys addrs that are above that limit to the HW
<rqou_> huh
<rqou_> but that won't work for devices like jpeg that only seem to itself be able to pass 32-bit physaddrs?
<sven> yeah
<sven> unless there's a second register for the upper half of the address or something like that
<sven> the DART also needs to support bypass mode
<rqou_> that's probably what the "bypass_addr_39_32" does then
<sven> the pcie ones e.g. don't
<rqou_> it's in the register that m1n1 seems to be calling TCR
<rqou_> at bit [23:16]
<sven> what i meant was that to program a 64bit address into dwc3 you write the halves to two separate 32 bit registers
<sven> maybe jpeg has something similar or maybe it really only does 32bit addressing
<sven> if it's the latter you're probably right
<rqou_> afaict it only does 32bit, but i've only been testing in m1n1 with DART enabled
<rqou_> fwiw t8110 doesn't seem to have any equivalent setting, so either i haven't found it or it cannot do that
<sven> maybe they just got rid of the bypass mode completely
<sven> is t8110 still limited to 32bit iovas?
<rqou_> no, 36 bits on everything except the apciec ones, which i haven't managed to check
<sven> okay, nice
<sven> on t8103 everything above 32bit got truncated even though technically the pagetables supported more
<rqou_> i should buy a thunderbolt widget just so i can do what you suggested (read register 0 once macos has set everything up)
<rqou_> fwiw i haven't _tested_ the full extent of the iova space
<rqou_> that's just from static analysis of macos drivers
<sven> okay, then it might still be limited to 32bit
<rqou_> the hardware config register says 36 bits
<rqou_> i can test it with the prores block later
<sven> would be interesting
<rqou_> the prores block itself is limited to 42 bit iova space
<sven> the t8103 limitation feels like legacy from the old iphones when they had 4kb DARTs
<rqou_> of the t8110 darts i've looked at, they all support 16 streams, 42-bit physaddrs, and 36-bit iova according to the parameter registers
<rqou_> the register interface seems to be built for up to 256 streams, but the first 16 seem to still be special with more features
<sven> interesting
<sven> i'd expect the thunderbolt ones to support at least 64
<rqou_> ok i really need to go out and buy a thunderbolt widget and take a look
<sven> I wonder if there's something cheap, I just used my tb dock that I had anyway
<sven> oh, you could also intercept the i2c reads from that tps6598x chip under the HV and pretend that you connected a thunderbolt cable
<rqou_> the t8110 dart in the t600x feels like a weird transitionary implementation with most of the features missing
<rqou_> the m2 might be much more "exciting"
<sven> yeah
<jannau> not sure about that, t8110 is used in a15 so it will probably be in m2 (if that doesn't skip a Axy generation)
<rqou_> yes, what i mean is that the m2 might have t8110 darts with version 2 instead of version 1
<rqou_> version 2 supports a lot more features
<rqou_> e.g. invalidating caches with an address range, extra page table levels, and a bunch of other acronym soup i don't understand
<sven> fun!
<rqou_> e.g. "STT" "CTC" "STC"
<rqou_> t8110 also seems to have settings related to controlling or otherwise affecting the number of outstanding transactions, but i don't understand anything about that either
<jannau> version is unfortunately not annotated in the ADT
<rqou_> it's found at register +0x8
<rqou_> bits [15:8] and [7:0] for major/minor
<sven> sounds like they intend to keep that version for a while then
<rqou_> feels like it
<rqou_> btw for reference: not applying the t8110 DART tunables still seems to work (consequences not yet determined), but not applying the prores tunables seems to make the block completely stop working
<sven> yeah, there’s no need for any dart tunables on t8103 or the either
<sven> *or t6000
<rqou_> the tunables code has a debug error message mentioning something about "client partitions"
<rqou_> but i don't know what that is either lol
<sven> as long as ignoring it works 🤷🏻‍♂️
<rqou_> that's why my current guess is that it might be something about caching or something about transaction queue limits
<rqou_> the scaler and prores blocks have a _huge_ pile of dart tunables
doggkruse has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
atsalyuk has quit [Ping timeout: 480 seconds]
atsalyuk has joined #asahi-re
atsalyuk has quit [Ping timeout: 480 seconds]
atsalyuk has joined #asahi-re
f14h has joined #asahi-re
atsalyuk has quit [Ping timeout: 480 seconds]
f14h has quit [Quit: f14h]
f14h has joined #asahi-re
f14h has quit [Remote host closed the connection]
alexsv has quit [Ping timeout: 480 seconds]
f14h has joined #asahi-re
f14h has quit [Remote host closed the connection]
f14h has joined #asahi-re
f14h has quit [Remote host closed the connection]
jaalsa has quit [Remote host closed the connection]