crabbedhaloablut has quit [Ping timeout: 480 seconds]
<marcan>
kettenis: really? this is a genesys chip... did they just use a designware SD controller inside?
yuyichao has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi-dev
PhilippvK has joined #asahi-dev
rkt has joined #asahi-dev
phiologe has quit [Ping timeout: 480 seconds]
rohin2 has joined #asahi-dev
rohin2 has quit [Ping timeout: 480 seconds]
WhyNotHugo has quit [Read error: Connection reset by peer]
d4ve has quit [Remote host closed the connection]
d4ve has joined #asahi-dev
WhyNotHugo has joined #asahi-dev
squags_ has joined #asahi-dev
squags has quit [Ping timeout: 480 seconds]
<marcan>
maz: good news, the linux pci side doesn't actually need any changes for m1pro after all
<marcan>
though I do think I found and fixed a bug
<kettenis>
marcan: the (usual) designware mmc controller isn't a standard SDHC one, so that is unlikely
<kettenis>
but maybe they use the PCIe endpoint controller
<maz>
marcan: I'll take patches for the bug!
<maz>
kettenis: I wouldn't be surprised if that was the case. that's the 'easy' way to bolt anything on PCI, leaving to SW to deal with the resulting crap.
aleasto has joined #asahi-dev
<j_ey>
arnd: can m1 mba dt come in after rc1? or does it need to wait for 5.17
<arnd>
j_ey: We normally don't take new material after the start of the merge window. For .dts files, there isn't much need anyway, as this can easily be shipped outside of the kernel
<j_ey>
fair, just wondering, it can wait!
<sven>
the usb reset "fun" won't be before 5.17 anyway
<j_ey>
sven: i wanted to get a j313/mba dt in, since m1n1 is checking compatible now
<sven>
fair enough :)
clefter has joined #asahi-dev
<kettenis>
having the dts in the linux repo really doesn't make a lot of sense for us
<kettenis>
we should just have blessed device trees in the m1n1 repository since the device tree that actually gets used will come from there
<j_ey>
sven: and also you need to turn disable some of the pcie stuff that's in the j274 dts otherwise it crashes on boot on the mba
<kettenis>
but what we really need is approved pwrmgr bindings before we start curating device trees
<sven>
yeah
<j_ey>
kettenis: we're likely to mirror the DTs in the linux repo anyway?
<kettenis>
marcan: i think it is time for another nudge for those
<sven>
j_ey: sure, but we could e.g. add the DTs to m1n1 as soon as they've been reviewed instead of waiting for the next merge window
<kettenis>
j_ey: yes, in principle, but I think iit would be ok for m1n1 to be "ahead" of the ones in the Linux repository from time to time
<j_ey>
sven: kettenis true
FireFox317 has quit [Ping timeout: 480 seconds]
FireFox317 has joined #asahi-dev
<kettenis>
fdisk did read the protective mbr alright
Dcow has joined #asahi-dev
phiologe has joined #asahi-dev
PhilippvK has quit [Ping timeout: 480 seconds]
bps has quit [Ping timeout: 480 seconds]
<marcan>
kettenis: I think "sync" just didn't work in busybox for some reason
<marcan>
no idea why
bps has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
<kettenis>
traditionally alls sync(8) does is call sync(2)
<kettenis>
and sync(2) only makes the kernel push out dirty buffers to disk asynchronously
<kettenis>
this is why you have to actually type sync three times for it to work ;)
<kettenis>
that still doesn't guarantee the data actually lands on stable storage
<kettenis>
it might still be cached by the disk itself
<kettenis>
flushing the disk cache is typically only done upon reboot or when the device is put into a deep sleep state
yuyichao has joined #asahi-dev
lethalnyan has joined #asahi-dev
lethalbit has quit [Remote host closed the connection]
<FireFox317>
marcan, commit 3226961a2fb679780d3672f1b970515b366b9b5c in m1n1 also includes writes some register, is this intentional? it is not mentioned in the commit message
<marcan>
firefox317: whoops, no, fixed
<marcan>
(force pushed because it was the latest commit anyway)
bps has quit [Ping timeout: 480 seconds]
<sven>
i've only seen sync fail so far on FAT32 filesystem fwiw. and that was because it didn't end up issuing the nvme flush command
<sven>
but everytime that command was issued any changes I did were commited to the disc even when i hard-rebooted afterwards
<sven>
ANS does complain about an "unclean reboot" though if you don't destroy the CQ/SQ pair
<marcan>
actually I say "it's what macos does" but rather, it's what I see in the mmiotrace
<marcan>
(i.e. that other bit turns on)
<marcan>
if what macos does is what the linux code says... then I wouldn't be surprised if macos is wrong :D
Dcow_ has joined #asahi-dev
Dcow has quit [Remote host closed the connection]
X-Scale` has joined #asahi-dev
<balrog>
still no xnu sources...
<marcan>
not like there's anything terribly interesting there these days...
<marcan>
the moved all the interesting bits to the KDK :/
X-Scale has quit [Ping timeout: 480 seconds]
<maz>
marcan: first patch seems reasonable. it's all black magic anyway.
desairc has quit [Quit: No Ping reply in 180 seconds.]
riatre has joined #asahi-dev
desairc has joined #asahi-dev
riatre_ has quit [Remote host closed the connection]
bps has joined #asahi-dev
<squags_>
might take a stab at some ANE RE bc it at least looks interesting compared to neural accelerators I've worked with before
<squags_>
just to be clear on the RE policy, logs and looking at intermediate/generated files are fair game, but disassembling disqualifies working on any Linux-end drivers?
clefter has quit [Quit: Connection closed]
X-Scale has joined #asahi-dev
X-Scale` has quit [Ping timeout: 480 seconds]
<marcan>
squags_: basically yes. you should probably use the hypervisor to work out the hardware interface.
<marcan>
disassembling isn't entirely banned outright, but I can't blindly trust that people will know how to do that without getting into trouble
<marcan>
e.g. I did some kext disasm the past two days because I was looking for very specific bits of information that I knew were not copyrightable (and would've taken me a significant detour to get with the hypervisor)
<squags_>
makes sense
<marcan>
so I ask that people don't disasm unless I am familiar with how they work, because I've been burned by that before
<marcan>
conversely, I worked out all of AIC/AICv2 without any disasm (though I might peek at the AICv2 driver a bit later only to confirm how the capability registers are interpreted; again a very specific thing that yields non-copyrightable information about the hardware)
<marcan>
squags_: I think ANS is largely fronted by an ASC, so you should be able to use the ASC tracing functionality in the hypervisor (and just write an ANS module as you learn more about it)
<sven>
it’s usually easier to just use the HV or blindly poke some registers anyway. Disassembling kexts is kinda ugly because it’s all c++ code with layers of IOkit indirections
<marcan>
yeah, especially if you want to get the big picture (which is where you run into copyright issues too)
<sven>
yeah
<sven>
oh, also strongly recommended: run strings on the kext and look for _debug and then pass that to xnu as bootargs. Some drivers are incredibly verbose
<marcan>
ah yeah, strings OK in my book, as you're largely just seeing log messages and such; just don't go around copying function names or something for no reason
<sven>
I hope “not blindly copying function names” is common sense ;)
<marcan>
I hope so, but you know...
<marcan>
(also, for register names that show up in strings I prefer to rewrite them too)
<squags_>
yeah my vague plan atm is to get a minimal ANE example going in MacOS, dump traces, then try getting it to run in m1n1/similar so I can fuzz out specifics
kit_ty_kate has quit [Remote host closed the connection]
<marcan>
yup, that's the general plan with anything
<marcan>
you're familiar with the existing userspace side ANE reversing?
<marcan>
geohot and some others looked at some stuff
kit_ty_kate has joined #asahi-dev
<marcan>
but nobody has looked at the ANS interface
<marcan>
those are two fairly disconnected aspects/drivers
<squags_>
I've seen that geohot look at stuff yeah, I'm taking a look at some of the ANE Mach-O files
<squags_>
I'm just curious how granular the instruction set will end up being
<marcan>
be particularly wary of looking at the userspace driver, as that's where you get tons of logic; we do have a hard ban on looking at the userspace GPU driver for this reason.
<marcan>
much safer to work out the binaries by differential analysis and such
<squags_>
noted
<squags_>
my intuition is that most of the graph -> model binary stuff wouldn't be particularly useful for like, OpenCL/Tensorflow/whatever else, just need to know opcodes and DMA logistics
<marcan>
yeah, the important bit is figuring out the hardware
<marcan>
then we can build whatever we want on top
<marcan>
we don't *want* to emulate anything macOS does layers above that (other than at extremely general publicly documented design levels *if and only if* they make sense)
<sven>
and we already know that macOS drivers aren’t perfect and we can sometimes do better :D
<Retr0id>
macos doesn't like working with my dell monitor over usb-c, I'm crossing my fingers and hoping that one day in the future it will Just Work under asahi
<j_ey>
Retr0id: i also have a non-working usbc monitor :<
clefter has joined #asahi-dev
<sven>
My monitor doesn’t work over DisplayPort. It only works if I put a dock with a HDMI converter in between
<sven>
I fear most of that will be issues inside the DCP firmware though :/
<j_ey>
that means its software fixable at least.. if not by "us"
<jannau>
I have an usb-c displayport adapter that doesn't work and a hdmi display which apple broke in iboot 12.0
bps has quit [Ping timeout: 480 seconds]
Dcow_ has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
Dcow has joined #asahi-dev
<povik>
let's see what's new audio-wise on the t600x...
<povik>
or not. secondary macos install has 2 hours remaining
<povik>
how can it be that slow...
<j_ey>
why not use the asahi installer? :P
leah has joined #asahi-dev
<jannau>
I have a secondary macos install for the hypervisor
<povik>
that skips over installing macos? TIL
kaprests has joined #asahi-dev
<j_ey>
povik: yes, just downloads the fw
<povik>
j_ey: and what happens if i run the macos kernel under hypervisor? does it find the primary macos install?
<povik>
how does macos decide where to take its rootfs from?
<j_ey>
i think uh..
<j_ey>
dunno!
<povik>
me neither :)
<sven>
no idea how it knows the correct rootfs but it won’t just take the primary one
<povik>
is it in the ADT perhaps?
<j_ey>
oh, so if you want to run macos, then you might need a full install
<sven>
yeah
<sven>
you can only get away with the installer if you just want to run linux
<povik>
would love to but we're not there yet :-p
yuyichao_ has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi-dev
yuyichao_ has quit [Ping timeout: 480 seconds]
<jannau>
there is a boot-uuid in "/chosen" in the ADT. I guess that's the rootfs
bps has joined #asahi-dev
<povik>
okay, something's different with the DMA it seems
<povik>
^ i take that back
<povik>
any guesses on what the sn012776 codec is? do you think it's an in-house apple part?
<povik>
hm, ifixit says it's texas instruments
<povik>
let's look at datasheets then
<povik>
ha, found a similar register map in the first datasheet i opened
<povik>
reset values match
<povik>
sn012776 ~ tas2764
bps has quit [Ping timeout: 480 seconds]
jerdnA has joined #asahi-dev
clefter has quit [Ping timeout: 480 seconds]
<povik>
how many microphones are there supposed to be on the mbp? could it be 12?
<povik>
supports-always-listening = 1
<povik>
^ what a nice property in the ADT
Dcow has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
King_InuYasha has quit [Remote host closed the connection]