<sven>
these are read and applied in AppleT8112TypeCPhy::performEFuseProgramming
<sven>
that function is very very verbose with debug prints
leafpaw has joined #asahi-re
<sven>
if you decompile it in ghidra you'll see patterns like fuse_full = *(uint *)((this + whatever) + some_offset); fuse_value = (fuse_full >> some_shift) & some_mask;
nsklaus_ has quit [Read error: Connection reset by peer]
millenialhacker has quit [Remote host closed the connection]
millenialhacker has joined #asahi-re
millenialhacker has quit [Remote host closed the connection]
<sven>
that's then followed up by *(uint *)(atcphy_mmio_ptr + some_offset) = *(uint *)(atcphy_mmio_ptr + some_offset) & some_mask | fuse_value << some_shift;
nsklaus has quit [Ping timeout: 480 seconds]
<sven>
the first one reads the fuse and extracts some bits, the second one applies the values to the atcphy. the atcphy regs can be matched up with what I have inside atcphy.c and are probably the same
<sven>
after that you'll always see a very big block which looks like if (this + whatever == something) { .... } and there will be lots of boilerplate in that block
<sven>
that's all just debug print stuff and can be used to match up the name of the fuse and otherwise ignored
<sven>
the other alternative to get them is to intercept reads/write to the fuse region and the atcphy fuse regs and play around with a few different patterns to see what gets stored where
<sven>
i've done that for the first two fuses or so before I got fed up, but maybe someone is more patient
millenialhacker has joined #asahi-re
millenialhacker has quit [Ping timeout: 480 seconds]
Dcow_ has joined #asahi-re
Dcow has quit [Ping timeout: 480 seconds]
millenialhacker has joined #asahi-re
millenialhacker has quit [Ping timeout: 480 seconds]