ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | Non-development talk: #asahi | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
rndm has joined #asahi-dev
rndm has quit [Remote host closed the connection]
kidplayer666 has quit [Quit: Connection closed for inactivity]
rndm has joined #asahi-dev
i509vcb has joined #asahi-dev
pounce has quit [Ping timeout: 480 seconds]
pounce has joined #asahi-dev
hightower3 has joined #asahi-dev
hightower2 has quit [Ping timeout: 480 seconds]
crabbedhaloablut has joined #asahi-dev
jeisom has quit [Read error: Connection reset by peer]
jeisom has joined #asahi-dev
i509vcb has quit [Quit: Connection closed for inactivity]
tbodt has quit []
tbodt has joined #asahi-dev
jeisom has quit [Ping timeout: 480 seconds]
tristan2 has joined #asahi-dev
tristan2_ has quit [Ping timeout: 480 seconds]
kidplayer666 has joined #asahi-dev
veebop has joined #asahi-dev
elvishjerricco has quit [Read error: No route to host]
elvishjerricco has joined #asahi-dev
capta1nt0ad has joined #asahi-dev
richyliu2 has quit [Ping timeout: 480 seconds]
richyliu2 has joined #asahi-dev
capta1nt0ad has quit [Ping timeout: 480 seconds]
pjakobsson_ has quit [Ping timeout: 480 seconds]
capta1nt0ad has joined #asahi-dev
capta1nt0ad has quit [Remote host closed the connection]
capta1nt0ad has joined #asahi-dev
kidplayer666 has quit [Quit: Connection closed for inactivity]
capta1nt0ad has quit [Ping timeout: 480 seconds]
kidplayer666 has joined #asahi-dev
capta1nt0ad has joined #asahi-dev
capta1nt0ad has quit [Ping timeout: 480 seconds]
russelltg has quit [Quit: Connection closed for inactivity]
RoguePlanet has joined #asahi-dev
RoguePlanet has quit []
<sven>
can anyone who has multiple M-series SoCs connect the same usb 3 device in the same orientation to all of them and trace atcphy? i want to confirm that there are no differences between the various generations
<sven>
mainly because there were some reports of usb3 being a bit flaky but I think that's because I have the atcphy/dwc3 order wrong in the current kernel
ydalton has joined #asahi-dev
jeisom has joined #asahi-dev
darkapex1 has quit [Ping timeout: 480 seconds]
jeisom has quit [Quit: Leaving]
nicolas17 has quit [Ping timeout: 480 seconds]
<DannyB>
Whee. i figured out why the m3 mmu hangs but i'm not sure what to do about it. It seems the state that m1n1 expects us to start in is not how things start for the m3. So for example, i have to clear the TCR register in chickens (or at least set it to the value that XNU does), to make the MMU init work, even though the MMU init *also* sets the TCR register itself. If i don't, the chip hangs when we set the SCTLR
<DannyB>
XNU resets the TCR very early and uses statically allocated bootstrap pagetables very early in the init until it sets up real pagetables.
<DannyB>
Unless someone has a better idea, i'm going to assume that the set of things that m1n1 wants is defined as "however the m1/m2 chip registers start right now", and ensure we put the m3 in the same state in chickens.
<DannyB>
The alternative would be to have a real spec of what we expect the invariants to be for m1n1, and put all the chips in that state. Maybe later
<DannyB>
register. So i assume something changed that is causing addresses to be translated or whatever in a way that we don't want on the m3, but not m1/m2. The MMU is not on when we get it on m3, so i have no idea why this has any effect, but it does!
<sven>
hrm, i think when i wrote the original MMU code I didn't rely on any previous state of the architectural registers
<sven>
if the chickens are correct maybe they changed something with how SPRR/GXF works?
<maz>
if they have stuffed non-architectural stuff in TCR_EL2, that's going to be fun. not.
<sven>
I'd try to remove the sprr/gxf init from m1n1's mmu and see if that changes anything. I think we only need that for the HV
<sven>
hrm, no, looking at it again we leave SPRR/GXF disabled in the MMU init and only prepare everything for the HV
<DannyB>
sven: I'll give it a shot
<DannyB>
sven: I have run it without gxf init and no dice
<DannyB>
sven: but not tried turning off SPRR permissions
<sven>
I think it's just the call to mmu_init_sprr() which may do weird things if they changed those regs
<DannyB>
there is also an additional MSR lockdown register that is write only
<DannyB>
which appears to be MSR lockdown for EL2
<DannyB>
but i set them to lockdown nothing in chickens (and have tried both ways there too)
<DannyB>
As for chickens themselves, i automated running every combination of lines in chickens for m3 and they all have the same behavior if i don't play with TCR (IE none of them change that we hang the chip the second MMU is turned on)
<DannyB>
I also was able to get most of the names/info of these chicken bits from the kernel debug info
<DannyB>
and they don't look related
<DannyB>
to MMU/SPRR
<DannyB>
(On the plus side, i did figure out 75% of the unknown chicken bits we are using on the M2 and documented them :)
<sven>
nice :)
<maz>
interesting!
<sven>
have you checked if the initial xnu pagetables look weird in some way or how that TCR value XNU differs from the one inside m1n1?
<sven>
I don't remember if the initial pagetables already use SPRR but they might
<DannyB>
Yes. I have the initial XNU TCR value, and decoded it, ours did not look crazy but maybe i decoded it wrong.
<DannyB>
The initial TCR, and bootstrap pagetables, are the same in XNU for 14.2 for m2/m3. I was going to look at older kernels today see if it was differnet before, and they just chose something in 14.2 that works for all
<DannyB>
That code is now old
<DannyB>
and definitely busted
<DannyB>
i'll update it to my hacked up current version
<sven>
j`ey: i'm only asking dumb questions anyway because that usually helps when i'm stuck at weird bugs like that :D
<DannyB>
Rubber duck debugging is great
<DannyB>
so please, have at it :)
<DannyB>
There is a bootstrap SPRR set of perms
<DannyB>
i know the value but don't know what sets it
<DannyB>
The initial SPRR perms for EL1 (set by iboot i guess?) is 0x2020A5203020FAF5LL
<sven>
hmm... how does the XNU TCR differ from ours?
<DannyB>
and the initial TCR set by XNU in common_start is 0x10800236511A511uLL
<sven>
or, wait, you first set it to the XNU value and then later m1n1 overwrites it and the MMU works then?
<DannyB>
yes
<sven>
huh
<DannyB>
even though nothing in between allocates memory
<DannyB>
right?
<DannyB>
Actually
<DannyB>
we configure TCR in mmu_configure after initing pagetables/etc
<DannyB>
so we do call memalign
<DannyB>
with whatever the TCR is set to initially
john-cabaj has joined #asahi-dev
<sven>
hrm, how would TCR matter before the MMU is on?
<j`ey>
but the mmu isnt on, right?
<DannyB>
also a good question
<sven>
before mmu_configure? I don't think so
<DannyB>
It's not
<DannyB>
because we would bai and issue a message if SCTLR_M is not
<DannyB>
on
<DannyB>
There are things that matter regardless of SCTLR state
<j`ey>
DannyB: have you tried setting TCR to some other value, not the one XNU uses?
<DannyB>
setting it to 0 works
<DannyB>
But there are things that matter in TCR even with MMU off
<DannyB>
MTX0
<DannyB>
for example
<DannyB>
"This control has an effect regardless of whether stage 1 of the EL1&0 translation regime is enabled or not."
<DannyB>
Top byte ignore
<DannyB>
i tink that's it
<DannyB>
just MTX1/0 and TBI1/0
<sven>
MTX should only matter if MTE is available but I don't think the M3 has that
<j`ey>
but presumably those aren't the issue, if setting everything to 0 is fine..
<maz>
dumping the id registers would settle it.
<DannyB>
BTW, can we talk about how weird
<DannyB>
"This affects addresses generated in EL0 and EL1 using AArch64 where the address would be translated by tables pointed to by TTBR0_EL1. It has an effect whether the EL1&0 translation regime is enabled or not."
<DannyB>
is
<DannyB>
what does it mean to affect the address generation if they would be translated, but it has effect whether the translation is enabled or not?
<DannyB>
i guess they mean it has effect if it would be translated if the translation was on, even if translation is off?
<sven>
huh, that does sound strange
<DannyB>
if so it would be easier to say "this bit affects all memory accesses"
<DannyB>
since they should be equivalent
<DannyB>
in any case, i'll read the ID registers when i get back to the laptop
<sven>
do they write to TCR in the chicken bit sequence inside xnu? maybe there's some truly weird hw bug where they have to do that specifically ordered w.r.t some chicken bit
<DannyB>
yes
<DannyB>
it's the first piece of common_start
<DannyB>
they write it on all m2/m3
<sven>
ah, right
<DannyB>
The open source code of this part is actually correct (IE it matches the compiled kernels):
<DannyB>
Anyway, let me turn off sprr perms and see if that works without messing with TCR.
ydalton has quit [Remote host closed the connection]
<sven>
it’s still so weird that first writing zero to tcr makes everything work
darkapex1 has joined #asahi-dev
<sven>
double checked that we also overwrite tcr from m1n1 so the previous value really shouldn’t matter :/
<DannyB>
yes
<DannyB>
i actually was going to ask if anyone has ever decrypted iboot on macos
<DannyB>
and see what the heck it's doing
<DannyB>
for m3 vs m2, if anything
<DannyB>
We are basically trying to figure out if iBoot has put it in a different state or what
<sven>
I think there are keys floating around for some iboots
<sven>
i'm still very confused because we overwrite TCR anyway. what state is left that get cleared by first setting that one to zero?
<sven>
*gets
<sven>
what happens if you just write the m1n1 value twice? does that also fix it? :D
<sven>
also looked for missing barriers but we have a isb inbetween setting up tcr and enabling the mmu
pounce has quit [Ping timeout: 480 seconds]
<nicolas17>
there are M2 keys
<nicolas17>
does anyone here have M3 Max? Siguza was looking for the bootrom version and CPRV (which appear on the DFU serial string)
<j`ey>
that's what DannyB has
pounce has joined #asahi-dev
nimprod3l has joined #asahi-dev
<maz>
huh, I never realised: generating a reset command from a CS on a M2 that is powered-off brings it back to life (tested on M2 Pro mini and M2 MBA). doesn't work on my M1 mini.
<kettenis>
works on my M1 mini
<kettenis>
there is a quirk though
<nicolas17>
CS?
<sven>
central scrutinizer, hardware that talks usb pd to send those Apple VDM commands
<kettenis>
it only seems to work if you power down the machine with CS connected to another machine
<maz>
maybe the FW on my M1 is a bit too old (never updated).
<kettenis>
asahi,system-fw-version: '12.3'
<kettenis>
guess I did update it at some point
<maz>
I'm still on whatever the thing came with.
<maz>
11.0 or similar.
<DannyB>
nicolas17: I have one. what do you need? (I'm not near it for a few hours, but can get it when i am back)
<DannyB>
@sven: We do call memory allocation functions prior to setting the TCR. But the MMU is disabled. So the only effect could be from top byte ignore i guess?
<DannyB>
(or MTE if it's supported and enabled)
<DannyB>
I have not tried writing our value earlier
<DannyB>
i wil do that
<nicolas17>
DannyB: enter DFU, run "irecovery -q" from the other machine, it will show CPRV and SRTG (bootrom version)
<DannyB>
gotcha
<nicolas17>
(you may want to redact ECID if you post the whole output :P)
<DannyB>
okay, i'll be near it in an hour or two
<nicolas17>
yeah no rush, thanks!
<sven>
im pretty sure the memory allocation functions just do internal bookkeeping and ignore whatever the mmu does
<DannyB>
One random thing i noticed - we init the mcc, and init the mmu, but we never actually set the cache to a known state (disabled or enabled). mcc_init just sets up the registers. Apple's MCC init explicitly disables and then enables cache.
<sven>
the mmu should work with MMC left in whatever state iboot leaves it - at least for m1
<DannyB>
got it
<DannyB>
in any cse, this has all been useful so far. i'll go try some stuff here and see what happens
<sven>
I‘m very curious about the root cause for this :)
pounce has quit [Ping timeout: 480 seconds]
pounce has joined #asahi-dev
pounce has quit [Ping timeout: 480 seconds]
pounce has joined #asahi-dev
pounce has quit [Ping timeout: 480 seconds]
pounce has joined #asahi-dev
elvishjerricco has quit [Ping timeout: 480 seconds]
<nicolas17>
macOS 14.2 beta 4 is out
nimprod3l has quit [Read error: Connection reset by peer]
nimprod3l has joined #asahi-dev
nyx_o has quit [Ping timeout: 480 seconds]
pounce has quit [Ping timeout: 480 seconds]
pounce has joined #asahi-dev
<john-cabaj>
Apologies if this has been discussed, but have any Asahi patches been upstreamed in 6.6 not in 6.5? It's easy enough to backport Asahi commits following the v6.6 tag, but if any patches fell in 6.6, it's trickier to determine.
nimprod3l has quit [Ping timeout: 480 seconds]
<j`ey>
john-cabaj: you mean you have a 6.5 kernel tree, and want to port the patches from the curent 6.6 asahi tree?
<j`ey>
but dont want to miss stuff that was upstreamed in 6.6?
pounce has quit [Ping timeout: 480 seconds]
crabbedhaloablut has quit []
<john-cabaj>
Correct
<j`ey>
Im not sure if there's an easy way to do that in general really
elvishjerricco has joined #asahi-dev
<john-cabaj>
There's definitely iommu changes between 6.5 and 6.6 that some Asahi patches will need backported, possibly others.
<john-cabaj>
But those weren't Asahi specific. Anything Asahi specific existing upstream in 6.6 not in 6.5 is a bit of a blind spot.
<j`ey>
git range-diff v6.5..asahi-6.5-29 v6.6..asahi-6.6-3 might help a bit
<john-cabaj>
Good idea, that's a start.
<john-cabaj>
Thanks
<j`ey>
or just switch to 6.6 :p
<john-cabaj>
Yeah, could do that too. Then will need backport kernels to previous releases. But that still might be easier.
elvishjerricco has quit [Remote host closed the connection]
blazra3 has joined #asahi-dev
blazra has quit [Remote host closed the connection]
blazra3 is now known as blazra
elvishjerricco has joined #asahi-dev
qyousef has quit [Write error: connection closed]
qyousef has joined #asahi-dev
kuruczgy has quit [Read error: Connection reset by peer]
d4ve has quit [Read error: Connection reset by peer]
amada95 has quit [Read error: Connection reset by peer]
coder_kalyan has quit [Read error: Connection reset by peer]
signaryk has quit [Read error: Connection reset by peer]
alethkit has quit [Write error: connection closed]
handlerug has quit [Write error: connection closed]
probie has quit [Write error: connection closed]
akspecs has quit [Write error: connection closed]
okt has quit [Write error: connection closed]
tsujp has quit [Write error: connection closed]
rosefromthedead has quit [Write error: connection closed]
pldtf has quit [Write error: connection closed]
ella-0 has quit [Write error: connection closed]
cds has quit [Write error: connection closed]
dubiousness has quit [Write error: connection closed]
dk_ has quit [Write error: connection closed]
elvishjerricco has quit [Remote host closed the connection]