<chaos_princess>
as in: genter to sptm with a "do start secondaries" syscall?
<sven>
I think SPTM does that all automatically. i've found a function in there that parses the ADT and finds the cpu-impl-regs and maps them
<sven>
but i haven't found the actual code that does the bringup now
<nickchan>
it definitely happens inside sptm according to some tweets i have seen
<sven>
if xnu did this it could also hijack SPTM
<nickchan>
it also has to because the core comes out of reset in EL2 with GL available but disabled
<sven>
yeah
<sven>
now i wonder how this is locked down in raw boot mode
<chaos_princess>
is there a chance that sptm is not the first/only code that runs there, and it jumps to iboot or sth?
<sven>
siguza suggested yesterday that it either has to be a sysreg or something that applies to all cores directly after they're out of reset or that they do something cursed like putting a single page under CTRR and locking down the secondary reset vectors to that one
<sven>
and then just disabled SPRR/GXF/etc. in there
<nickchan>
there are like 4 ctrr regions that can be configure on m4
<chaos_princess>
can we read the state of those?
<nickchan>
it's cpu registers so it should be possible
<sven>
unless they're locked down to just return 0 or whatever, yes
<nickchan>
hold
<chaos_princess>
would be interesting to do for both raw and macho and compare
<chaos_princess>
and in general just see what is there
<sven>
yeah
<nickchan>
so m1n1's apple_regs.json already has CTRR A and B
<nickchan>
but m4 supposedly also have C and D
<nickchan>
okay so
<nickchan>
try s3_0_c11_c6_6 for CTRR_C_LWR_EL2 and s3_0_c11_c6_7 for CTRR_C_UPR_EL2
<nickchan>
and s3_0_c11_c7_0 for CTRR_D_LWR_EL2, s3_0_c11_c7_1 for CTRR_D_LWR_EL2
<nickchan>
erm s3_0_c11_c7_1 should be CTRR_D_UPR_EL2
<j`ey>
/win 108
<j`ey>
woops sorry
<nickchan>
but of course if isa extensions are being disable it's also possible that those regs just don' twork
<chaos_princess>
doesn't hurt to try
<chadmed>
they shouldnt be disabled if a macho m1n1 is enrolled though right
<chaos_princess>
mischa85: could you try reading out all ctrr regs in both modes
<nickchan>
chadmed: they will not be disabled in that situation but it would be EL2 under sptm
<nickchan>
also
<nickchan>
in my understanding CTRR should have multiple parts, EL1 restriction, EL2 restriction and DRAM restriction
<nickchan>
but m1n1's apple_regs.json makes absolutely no mention of anything related to DRAM restrictions
<nickchan>
EL1 restriction and EL2 restrictions limit instruction fetches, DRAM restrictions ensure memory ranges cannot be written to
<sven>
dram restriction is MMIO iirc
<sven>
and the sysreg restrictions at least limit writes to caches
<sven>
didn't the sysregs also change when they introduced PPL? i'm not sure they still limit instruction fetches these days
pb17 has quit [Ping timeout: 480 seconds]
<mischa85>
chaoss_princess: currently A and B are defined in apple_regs, how do i translate s3_0_c11_c6_6 to "enc": [3, 4, 15, 9, x ]
<mischa85>
x is 1, 2, 3 and 4 for A and B
<sven>
s3_0_c11_c6_6 is [3, 0, 11, 6, 6] or what do you mean?
yuyichao_ has quit [Ping timeout: 480 seconds]
<mischa85>
oh i expected some complicated logic behind it again
<mischa85>
excuse me, on it
<nickchan>
you can also mrs((3,0,11,6,6)) in the shell
<nickchan>
okay that's _EL1 but since VHE is always active that should just be _EL2
<mischa85>
yes these are the same for EL2
<mischa85>
correct
<nickchan>
anyways
<nickchan>
so like
<nickchan>
apple used 3 CTRR regions for it but previous chips can only do 2
<nickchan>
sven: what do you think
<sven>
if this was my machine I'd dump these regions and take a look at them, but since they contain apple code we shouldn't share them unfortunately . they seem to all be rather large though.
<sven>
also dump that cpu start region and look for the IORVBAR value or however that's called
<nickchan>
sven: /cpus/cpu<n>/cpu-impl-reg
<nickchan>
that should be the IORVBAR
<sven>
i'd take a look at that value and see if it happens to point into one of these CTRR regions
<sven>
especially for the secondary cores
pb17 has joined #asahi-re
mattia013 has quit [Remote host closed the connection]
mattia013 has joined #asahi-re
<nickchan>
mischa85: maybe do read64(u.adt["/cpus/cpu1"].cpu_impl_reg[0]) following sven's advice
<nickchan>
not sure which core m4 boots on but check that as well
<mischa85>
cpu4
<mischa85>
i'll check
<mischa85>
cpu0-9: 0x110010005d68001, cpu 10-16: 0x210010005d68001
<nickchan>
sven: it's all locked!
<sven>
hah
<sven>
not inside CTRR though
<sven>
but that explains why you had issues bringing up the other cores
<nickchan>
okay so supposed put code at 0x10005d68000 and supposedly all other cores would end up there
<nickchan>
mischa85: hmmm... is that inside m1n1?
<sven>
also, where is m1n1 located?
<sven>
yeah, could be that it was just locked by m1n1
<mischa85>
m1n1 base: 0x10005d68000
<nickchan>
okay so that's right at m1n1 base and apple goes out of the way to make sure it's not the entry point *either*
<nickchan>
because entry point is +0x800
<nickchan>
it's almost as if it's designed for m1n1
<nickchan>
ah wait
<sven>
doesn't m1n1 set that to its reset vectors as well?
<nickchan>
it might be because of alignment requirements on that reg
<sven>
but i don't think we lock that reg down
<nickchan>
but on older socs bit 11 can be configured
<sven>
m1n1's entrypoint is 0x800 from its base
<nickchan>
sven: yep and it is secondary entry point as well
<sven>
yeah
<sven>
the only weird part is that the reg is locked
<sven>
or does it lock automatically after writing to it these days?
<nickchan>
mischa85: you have not attempted to start secondaries in the same boot right
<mischa85>
nickchan: no for sure not. just the shell on bringup m1n1
<nickchan>
okay so it's iboot that did that
<nickchan>
mischa85: maybe start offset is wrong?
<nickchan>
have you tried every 0x4000 from pmgr base to a max of 0x100000?
<mischa85>
you mean this one? misc-cores-offset = 557056 -> 0x88000 (same as m3)
<nickchan>
mischa85: yeah
<nickchan>
so it's in the adt these days interesting
<nickchan>
back then we bruteforce
<mischa85>
yeah there are quite some new values compared to t6031
<mischa85>
there's also cluster-ctl-offset = 131072
pb17 has quit [Ping timeout: 480 seconds]
pb17 has joined #asahi-re
pb17 has quit [Ping timeout: 480 seconds]
pb17 has joined #asahi-re
mischa85 has quit [Ping timeout: 480 seconds]
mischa85 has joined #asahi-re
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-re
mischa85 has quit [Ping timeout: 480 seconds]
mischa85 has joined #asahi-re
pb17 has quit [Ping timeout: 480 seconds]
pb17 has joined #asahi-re
swiftraccoon has quit [Remote host closed the connection]
swiftraccoon has joined #asahi-re
glem81005488 has quit [Quit: bye.]
swiftraccoon has quit [Ping timeout: 480 seconds]
glem810054889 has joined #asahi-re
swiftraccoon has joined #asahi-re
nela has joined #asahi-re
swiftraccoon has quit [Remote host closed the connection]
swiftraccoon has joined #asahi-re
pb17 has quit [Ping timeout: 480 seconds]
pb17 has joined #asahi-re
okb has quit [Read error: Connection reset by peer]