ransom has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
_whitelogger has joined #asahi-dev
ransom has joined #asahi-dev
ransom_ has joined #asahi-dev
ransom has quit [Ping timeout: 240 seconds]
<maximus64>
I updated system register dump wiki page with Darwin dump and Firestom while running m1n1
_whitelogger has joined #asahi-dev
ransom_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
maor26 has joined #asahi-dev
amw has quit [Ping timeout: 256 seconds]
hir0 has joined #asahi-dev
amw has joined #asahi-dev
<maximus64>
here is the bits that is difference bettwen darwin and m1n1: https://termbin.com/tgx8
<maximus64>
there is alot more diff but I only include the one that we have bit field definition for
<maximus64>
darwin have more chicken/kill bit set that look interesting
<marcan>
maximus64: which darwin version is this?
<marcan>
it is possible they added more chicken bits since the one I looked at
<maximus64>
let me check
<marcan>
also, which core?
<marcan>
since the chicken bits are different for p/e
<maximus64>
I dump all 8 core for darwin
<winocm>
🐓
<marcan>
other than the HID bits, all the other differences are expected
<maximus64>
Darwin version is 20.3.0 XNU: 7195.81.3~1
TellowKrinkle[m] has quit [Quit: Idle for 30+ days]
<maximus64>
m1n1 side I cheat and dump only first core of each clusters
<maximus64>
all the HID difference is for the Firestorm. I notice that EHID -> Icestorm HID -> Firestorm. E probably mean efficiency heh
<maximus64>
ahh that already mention in the wiki page
<maximus64>
also interesting bit is that some registers fire MSR exception trap when try to read in darwin but no exeception when read in m1n1. Maybe it is security registers that got lock
amw has quit [Ping timeout: 240 seconds]
hir0 has quit [Quit: hir0]
Bluerise has joined #asahi-dev
VinDuv has joined #asahi-dev
maor26 has quit [Remote host closed the connection]
amw has joined #asahi-dev
maor26 has joined #asahi-dev
leah2 has quit [Ping timeout: 272 seconds]
leah2 has joined #asahi-dev
amw has quit [Ping timeout: 256 seconds]
vimal has quit [Ping timeout: 240 seconds]
DarthCloud has quit [Remote host closed the connection]
DarthCloud has joined #asahi-dev
grumble has quit [Quit: ACCORDING TO ALL KNOWN LAWS OF AVIATION THERE IS NO WAY A BEE SHOULD BE ABLE TO FLY ITS WINGS ARE TOO SMALL TO GET ITS FAT LITTLE BODY OFF THE GROUND THE BEE OF COURSE FLIES ANYWAY BECAUSE BEES DON'T CARE WHAT HUMANS THINK IS IMPOSSIBLE]
grumble has joined #asahi-dev
VinDuv has quit [Quit: Leaving.]
Necrosporus has quit [Read error: Connection reset by peer]
Necrosporus has joined #asahi-dev
riker77 has quit [Ping timeout: 264 seconds]
riker77 has joined #asahi-dev
<modwizcode>
That's... interesting
<modwizcode>
I've been wondering how much to emulate the chicken bit registers. I think some of them I'll have to emulate for real (Fast IPIs) the rest probably need minor emulator so I can get "read as written" which requires handler support in QEMU I think
<marcan>
modwizcode: fast IPIs are not chicken bits
<marcan>
you do not need to emulate any chicken bits at all
<marcan>
just have those registers as dumb memory
<marcan>
you do need to emulate the Apple vendor-specific registers that have functions that matter :)
<modwizcode>
okay I guess that's more semantics. It's part of a register that has some chicken bits isn't it? Or maybe just my confusion
<marcan>
nope
<marcan>
HIDx are chicken bits
<marcan>
and pretty much only chicken bits
<marcan>
IPIs have their own registers not mixed with everything else
<modwizcode>
Idk how much you know about qemu but given what you know about the core, do you think it will end up being best to put those register defs in their own "apple core" specific CPU handling file? Or just stuff them in with the 64-bit core types?
<marcan>
I don't know the codebase, but I'm guessing apple stuff should probably be implemented in separate files
<marcan>
register defs too
<modwizcode>
I'm trying to not couple things to the "M1" code (as I refer to the SoC device complex) since I'm assuming that future SoC's will potentially be different enough to merit their own distinct SoC
<modwizcode>
But there's very little convention for this.
<modwizcode>
in fact there's hardly any convention for anything in qemu. even file names are randomly distributed between "-" seperators and "_"
<marcan>
heh
<modwizcode>
The biggest issue I've encountered was with working on AIC. There's no proper way to sanely define core local aliases.
<modwizcode>
The sanest way is to abuse the thread local "current_cpu" variable and hope that the mmio access is from the same thread (which seems to be always true for now but it's a hack). Defining core local memory maps is possible, but then the peripheral can't control the mapping fully so the code ends up all over the place.
<modwizcode>
marcan: have you played with the USB controllers at all? I'm probably going to throw a dwc3 peripheral at the right address and export it in the device tree, hopefully I don't need to add apple specific quirks.
<marcan>
there's a whole PHY init thing that needs to happen, which is outside the generic dwc3 part
<modwizcode>
I have no experience with USB stuff directly, is that something kind of standard, but vendor specific?
<Bluerise>
that's vendor specific
<Bluerise>
but if it's for qemu, the phy shouldn't matter
<Bluerise>
I mean, you should know that Apple will be touching a few phy registers, but for a virtualized dwc3, the phy doesn't really exist
<modwizcode>
The point of my work on emulation is partially to allow as indistinguishable from hardware as is reasonably possible
<modwizcode>
At least until I'm aware of exactly what can be relaxed.
<modwizcode>
It would be pointless to just emulate enough for Linux to work since there's already plenty of non-apple ARM64 platforms in QEMU.
<modwizcode>
I agree though that it will likely be stubs
<marcan>
you can't really emulate phy stuff, because it's analog
<marcan>
but you would have to emulate it enough that the OS can init it
<marcan>
i.e. handle any status/busy bits and things like that
<Bluerise>
yup
<modwizcode>
QEMU->CXXRTL+SPICE ;p
<marcan>
did you ver see the frankenstein thing I did to make IOS LLE emulation in dolphin work?
<marcan>
running bootmii under dolphin :p
<modwizcode>
I think I tried to look at that once but I don't know if I really dug in enough
<modwizcode>
or was that you throwing dolphin+skyeye together?
<marcan>
yeah, that
<modwizcode>
yeah I don't think you ever actually fully discussed that anywhere
<modwizcode>
I looked for more info anyway ;)
<marcan>
IIRC I did post the code at some point
<modwizcode>
You posted the skyeye stuff eventually but that was about it
<marcan>
and some dolphin devs have used it AIUI
<modwizcode>
Yeah I think so. I follow some random IOS emulation related issue still on the github
<modwizcode>
I should finish my documentation of some of the OS primitives in IOS
<modwizcode>
it's a pretty neat little minimal threading system
<modwizcode>
heh
<marcan>
the sad part was that you couldn't really make dolphin+skyeye "generically useful"
<modwizcode>
I can think of a lot of reasons but what was the practical issue there?
<marcan>
my code did "proper" IPC bridging, which works for IOS and BootMii, but since skyeye can't actually boot full IOS (no USB/WiFi, I had patches in to disable those drivers) you couldn't actually use it to boot wii apps
<modwizcode>
ahh
<marcan>
for dolphin dev, what people did was use hybrid LLE+HLE, where only the things IOS under skyeye could handle were passed through
<marcan>
but that implies the Nintendo IPC usage model
<marcan>
which is different (and much worse) than the one BootMii uses
<marcan>
:)
<modwizcode>
Yeah I uh thought it was weird
<marcan>
so, can't have it both ways, unless you go about trying to autodetect what's on either side, and that way lies madness
<modwizcode>
I was trying to figure out if (besides the doorbell interrupts) the IPC couldn't have just basically used normal memory lol
<marcan>
it could've, as long as you put the pointers in separate cache lines
<modwizcode>
Right because they're not coherent
<marcan>
(or just have both sides always use uncached accesses)
<modwizcode>
yeah I guess that just works too
<marcan>
my ring buffer thing was much nicer though :)
<marcan>
you know why I designed it like that?
<modwizcode>
why?
<marcan>
it had to be as fast as possible
<marcan>
because before we discovered AHBPROT, this was going to be a backend for linux
<modwizcode>
oh right
<marcan>
linux was literally doing IPC calls for every readl() and writel() into those devices
<marcan>
e.g. EHCI
<modwizcode>
yikes
<marcan>
and it *worked*
<marcan>
I had it down to nanoseconds for posted writes
<marcan>
and like a microsecond or less for reads IIRC
<modwizcode>
I would have said screw it and just ended up implementing a poor copy of high level IPC like IOS does
<marcan>
yeah but then what, implement high level drivers in linux?
<modwizcode>
I guess yeayh
<tmlind>
heh i like the idea of using interrupt-names to specify the timer role :) that issue has been bugging many folks..
<marcan>
yeah, dummy irqs are pretty terrible :)
<marcan>
and it's fully backwards compatible!
<marcan>
not forwards though, but well, not like it matters for a new soc
<marcan>
well, it's forwards compatible for dts that *don't* plan on skipping interrupts
<tmlind>
yeah let's hope robher likes that solution too
<marcan>
I don't see why not, it's the whole point of interrupt-names, right?
<tmlind>
right, all the earlier suggested solutions have been trying to add new timer specific properties
<marcan>
oh hah
<marcan>
this one seemed... rather obvious to me
<tmlind>
well interrupt-names does not help with clocksource timers with no interrupts, but that's another story, and usually there are only few of those
<marcan>
yeah, this one seems particularly well suited to the arm timers because they're weird in that they're architected into the CPU, but the IRQs are platform dependent
<marcan>
which is a very weird arrangement
<modwizcode>
It is quite strange
<marcan>
what apple did almost makes more sense here; they're tightly coupled into FIQ...
<marcan>
now if only they'd added some freaking status/mask registers
<marcan>
*that* is ridiculous
<modwizcode>
in qemu most of the time it seems that they end up fed into the IRQ controller which then feed back out IRQ and FIQ lines for each CPU. At least GIC can I think remap them however you please, although I know little about the GIC.
<modwizcode>
I thought you found a bit that helped with that marcan
<marcan>
only masks for the *guest* timers
<modwizcode>
oh
<marcan>
the HV timers have no masks, and nothing anywhere has status bits
<marcan>
oh yeah, not sure if I mentioned, but this thing apparently has a standard-ish vGIC
<modwizcode>
uhh
<marcan>
with its maintenance interrupt hardwired... to *IRQ*
<modwizcode>
that's
<marcan>
in parallel with AIC.
<marcan>
ORed.
<modwizcode>
...
<modwizcode>
but just the vGIC I assume not the rest of it?
<marcan>
yeah, just the virtualization part
<modwizcode>
well that's probably definitely the easiest way to solve that issue
<modwizcode>
I don't look forward to figuring out how to make that work
<marcan>
I was talking with maz about this, Linux should be able to use it pretty easily
<modwizcode>
means I have to read the docs for the v3 GIC I think
<marcan>
well, you don't have to care until you try to emulate virtualization
<modwizcode>
and maybe figure out if I can seperate the vGIC code enough, I wonder if it's easiest to just replicate enough to work in the AIC part
Bluerise has quit [Quit: brb]
<modwizcode>
I assume though that it means that there's a parallel interrupt controller driver for a GIC (or at least running under a vGIC) so that macOS can be emulated.
Necrosporus has quit [Ping timeout: 256 seconds]
VinDuv has joined #asahi-dev
Necrosporus has joined #asahi-dev
<jannau>
10_AnyesS3!17
<kettenis>
time for a new password!
<maximus64>
lol
KindOne has quit [Ping timeout: 272 seconds]
KindOne has joined #asahi-dev
<luca020400>
when you think the screen is locked and you type the password.
<dhewg>
focus follows mouse is good at that too
<luca020400>
I leaked my github password because of focus. so yeah