<nicolas17>
I'm just exploring the possibilities, with my current code it would be completely impractical to decode all the methods
<Dcow[m]1>
thanks nicolas17
<Dcow[m]1>
yeah I know installer has it. I was thinking that maybe we can deliver only package deps with installer if macos has it. but ok.
jn has quit [Read error: Connection reset by peer]
jn has joined #asahi-dev
kylealanhale has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kode54 has quit [Server closed connection]
kode54 has joined #asahi-dev
bpye has quit [Server closed connection]
bpye has joined #asahi-dev
nicolas17 has quit [Ping timeout: 480 seconds]
tardyp has quit [Server closed connection]
tardyp has joined #asahi-dev
nkaretnikov has quit [Server closed connection]
nkaretnikov has joined #asahi-dev
pzcz has joined #asahi-dev
pzcz has quit [Remote host closed the connection]
pzcz has joined #asahi-dev
pzcz has quit [Remote host closed the connection]
axboe has quit [Server closed connection]
axboe has joined #asahi-dev
pzcz has joined #asahi-dev
pzcz has quit [Remote host closed the connection]
WhyNotHugo has quit [Server closed connection]
WhyNotHugo has joined #asahi-dev
coder_kalyan has quit [Server closed connection]
coder_kalyan has joined #asahi-dev
<nametable[m]>
Is tethered boot with m1n1 the best bet for beginning to reverse engineer hardware and test changes to the kernel? So far I have tested the release version of Asahi Linux, but now I am looking to start messing around with the hardware
<nametable[m]>
Also, does m1n1 boot either Linux or MacOS? If I understand right, m1n1 just allows a debug interface over USB while the system is running... letting me examine and change registers....?
gpanders_ has quit [Server closed connection]
gpanders_ has joined #asahi-dev
nyx_o has quit [Server closed connection]
nyx_o has joined #asahi-dev
pzcz has joined #asahi-dev
pzcz has quit [Remote host closed the connection]
balrog has quit [Server closed connection]
balrog has joined #asahi-dev
kylealanhale has joined #asahi-dev
megalokafes_ has quit [Server closed connection]
megalokafes_ has joined #asahi-dev
jeffmiw has quit [Ping timeout: 480 seconds]
Simonx22 has quit [Server closed connection]
Simonx22 has joined #asahi-dev
kevans91 has quit [Server closed connection]
kevans91 has joined #asahi-dev
winter has quit [Server closed connection]
winter has joined #asahi-dev
King_InuYasha has quit [Server closed connection]
King_InuYasha has joined #asahi-dev
<j`ey>
nametable[m]: yes tethered m1n1 is what you want
Darkmatter66 has quit [Server closed connection]
Darkmatter66 has joined #asahi-dev
kylealanhale has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
skipwich has quit [Server closed connection]
skipwich has joined #asahi-dev
Major_Biscuit has joined #asahi-dev
juancri has joined #asahi-dev
Major_Biscuit has quit [Ping timeout: 480 seconds]
Glanzmann has quit [Quit: leaving]
kylealanhale has joined #asahi-dev
kylealanhale has quit [Ping timeout: 480 seconds]
tbodt has quit [Server closed connection]
tbodt has joined #asahi-dev
MajorBiscuit has joined #asahi-dev
rbenua has quit [Server closed connection]
rbenua has joined #asahi-dev
koorogi has quit [Server closed connection]
koorogi has joined #asahi-dev
hitmoon has joined #asahi-dev
pzcz has joined #asahi-dev
pzcz has quit [Remote host closed the connection]
hays has quit [Server closed connection]
hays has joined #asahi-dev
Z750 has quit [Server closed connection]
Z750 has joined #asahi-dev
joske has joined #asahi-dev
<joske>
marcan: I'm trying to adapt the asahi-alarm-builder for manjaro linux, I have a question regarding the pacstrap step, where does this asahilinux-keyring package come from? Is it already in the Arch repos?
<joske>
chadmed: thx, indeed, I just figured that out myself :-) now this step works
<marcan>
joske: pacstrap pulls it from the host before all those scripts start
<marcan>
including repos etc
<marcan>
so the host needs to have it installed first
<marcan>
(that's the only package needed since otherwise we start with a fully baked ALARM tarball)
<arnd>
sven: I'm trying to make sense of the nvme+sart driver, as it feels a bit awkward to have a custom interface for something that is half an IOMMU. I think i would be nicer to either have sart fully integrated with the apple-nvme driver, or more generic with its own dma_map_ops or as part of drivers/iommu.
<arnd>
do we know of any devices other than the NVMe controller using sart or a related block?
<joske>
marcan: thx, I'm still confused about this line: mount --bind "$ROOT" "$ROOT"
<sven>
arnd: i wanted to reply later today but essentially the issue is that NVMe has two IOMMU-like things. once this tightly coupled NVMMU for most commands and then this SART thing for buffers like the syslog and some vendor-specific NVMe commands that don't use the normal PRPs
<sven>
so i can't make it dma_map_ops because then everything would go through it
<sven>
so far it's only been used for nvme
<arnd>
how is the NVMMU represented in the DT?
<sven>
it's part of the NVMe driver because it's very tightly coupled with command submission
<arnd>
ok
emptynine has quit [Server closed connection]
emptynine has joined #asahi-dev
<sven>
there's one array (which apple calls linear sq) where you setup the command and then another array where you set it up again (which apple calls NVMMU)
<sven>
they split it because they have this fake-hypervisor which setups the latter while the kernel sets up the first
<sven>
and if it's more than two pages they setup the PRP structure twice, once inside kernel-controller memory and a second time inside fake-hypervisor-controlled memory
<sven>
no need to do that inside linux ofc
<sven>
*kernel-controlled
joske has quit [Remote host closed the connection]
joske has joined #asahi-dev
<sven>
I don't have any strong preference for keeping SART separate. it just felt like a different device.
<sven>
it's the only thing that changed between M1 and M1 Pro/Max fwiw
<arnd>
sven: so there is no address translation at all between NVMe and RAM, but multiple address filters?
<sven>
yes
Ariadne has quit [Server closed connection]
Ariadne has joined #asahi-dev
<arnd>
sven: ok, thanks for the background, I'll read the implementation again to get to a more informed opinion. For the moment, I'm leaning towards "not-in-my-backyard" and would rather see the SART code merged into the nvme driver because that keeps it out of drivers/soc ;-)
<maz>
sven: I had similar questions about the rtkit driver, which smells a lot like a "standard" mailbox driver...
<arnd>
sven: not sure if that has any implications on the DT binding, kettenis might have an opinion on what representation of the SART makes the most sense for openbsd or u-boot though
tmlind has quit [Server closed connection]
tmlind has joined #asahi-dev
<sven>
about to grab lunch, can reply about rtkit later. but if we move rtkit to mailbox we have to keep SART separate because both rtkit buffers and nvme vendor-specific commands (which we may or may not need in the future) are filtered by SART
<arnd>
regarding the rtkit driver, the mailbox subsystem is generally a very leaky abstraction, but the one thing it does provide is a way to multiplex a number of mailbox instances over a shared hardware block, and a somewhat generalized DT binding for describing that multiplexing
_alice has quit [Server closed connection]
_alice has joined #asahi-dev
skoobasteeve has quit [Server closed connection]
skoobasteeve has joined #asahi-dev
the_lanetly_052 has joined #asahi-dev
pzcz has joined #asahi-dev
pzcz has quit [Remote host closed the connection]
kameks has joined #asahi-dev
robher has quit [Server closed connection]
robher has joined #asahi-dev
KDDLB has quit [Server closed connection]
KDDLB has joined #asahi-dev
WindowPain has quit [Server closed connection]
Skirmisher has quit [Server closed connection]
Skirmisher has joined #asahi-dev
WindowPain has joined #asahi-dev
povik has quit [Server closed connection]
povik has joined #asahi-dev
chadmed has quit [Remote host closed the connection]
<marcan>
joske: IIRC pacstrap really wants the target dir to be a mountpoint
os has quit [Server closed connection]
os has joined #asahi-dev
<sven>
alright, rtkit. for nvme that thing is extra awkward because all we need there is boot and shutdown and no more communication after that. that already doesn't fit well with the mailbox API.
<sven>
marcan knows more details about SMC, but there some parts are handled by the rtkit core (syslog, etc.) while others are handled by the SMC driver. that would be split across mailbox and SMC then. buffers are also mapped as if they are MMIO there and handed out by the co-processor
<sven>
so if we had this inside mailbox we'd have some quirks for probably every single co-processor
<marcan>
maz: if you want my personal opinion on mailbox, using that subsystem at all was a mistake because it just *sucks*
<marcan>
it is poorly designed, and different drivers interpret its design in different, incompatible ways
<marcan>
but now we're stuck with it, fine, as a dumb low-level abstraction on top of the raw mailbox hardware
<marcan>
but trying to use it above RTKit is something we thought of, and decided would be an even worse idea because it clashes even more with the mailbox design
caef^ has quit [Remote host closed the connection]
<marcan>
RTKit is really a higher level interface and needs to deal with things like buffer/memory management too
<sven>
I also briefly looked into remoteproc, but that seemed to to mostly deal with virtio and firmware loading which we both don't have here
<marcan>
yeah
the_real_briel[m] has quit [Server closed connection]
the_real_briel[m] has joined #asahi-dev
<marcan>
arnd: our conclusion re: mailbox was that because Apple's coprocessors generally only do one thing, trying to use the mailbox abstraction to provide the multiplexing is just a waste of time
<arnd>
right, makes sense
<marcan>
and the existing abstraction does *not* work properly, IIRC due to how it handles queuing, if we try to expose the different endpoints as different channels
<marcan>
the only copro that does have a ton of interfaces some of which are logically separate is DCP; that one has sub interfaces for dealing with things like DisplayPort hardware and the DP2HDMI etc, besides the main giant dcpep
<marcan>
*but* display controllers are a tightly tied mess already, so I don't see using different drivers for that in linux buying us anything really
<marcan>
it'd just end up being a pile of drivers with a ton of incomprehensible cross-dependencies
<marcan>
might as well just accept that there's no good way to do it and go monolith; at least it won't be a gpu+display monolith like x86 GPUs
<sven>
yeah, the mailbox subsystem assumes hardware channels with independent status bits
<arnd>
is there some more information about the rtkit documented somewhere? I'm probably still missing a few of the fundamental bits
<marcan>
rtkit is just apple's RTOS; we use the name to refer to the shared framework it implements over the mailbox
<arnd>
are there multiple instances running the same type of firmware on the chip but with different purposes?
<marcan>
by the way, there are mailboxes that *don't* do RTKit
<marcan>
SEP, in particular
<marcan>
yes
<marcan>
e.g. SMC will reuse all of the RTKit stuff as-is from the NVMe submission, but instead builds up a key/value interface over a user endpoint
<marcan>
GFX also will, though I'm dreading having to do more refactoring of mailbox if it ends up being a performance bottleneck there, since there it actually matters
<marcan>
same with PMP and everything else
pzcz has joined #asahi-dev
<marcan>
DCP too
<marcan>
SMC, NVMe, and DCP pretty much cover all the "weird" combinations of memory management for RTKit core endpoints, and all three are already up and running, so the current RTKit module design is already fairly well proven in that regard
pzcz has quit [Remote host closed the connection]
<marcan>
(this is one reason we waited to submit until now, we wanted to iterate on that a bit)
limegorilla[m] has quit [Server closed connection]
limegorilla[m] has joined #asahi-dev
<sven>
thunderbolt uses a different HW mailbox interface but the ~same rtkit stuff as well
<marcan>
yeah
<marcan>
so for that having a separate mailbox driver does kind of make sense
<sven>
just more horribly because if you lock that processor up or do something wrong the entire SoC will reset *sigh*
<marcan>
that is the SMC RTKit backend (there's another layer in there because I want the upper level SMC stuff to work on T2 and pre-T2 x86 macs too, which do not use RTKit)
<marcan>
(pre-T2 Macs do some ioport interface for the key/value access, while T2 macs do some ACPI thing)
<marcan>
note: the atomic thing is a special case for sending the final system shutdown/reboot command to SMC, which has to happen in atomic context; this is probably going to be the only consumer of that particular API
<arnd>
so T2 macs use the same rtkit stack for SMC as the M1 macs?
<marcan>
(it is not spinlocked properly either, I gave up on that since it doesn't matter for this sole use case and trying to do it properly was too much of a mess)
<marcan>
no, T2 macs use a different thing (they do use RTKit internally but I don't think any of that is exposed)
<marcan>
there's up to four abstractions involved in SMC
<marcan>
macsmc-* drivers instantiate mfd sub-devices on top of macsmc, using a generic, higher-level key-value API
<marcan>
macsmc is fairly thin, it mostly provides helpers for reading/writing different key types, enumerating/searching for keys, and does the general mfd registration
<marcan>
macsmc-rtkit is the actual mfd parent driver, it just initializes RTKit and provides the backend ops and then calls macsmc to actually register the mfd and everything on top
<marcan>
we'd have a macsmc-acpi and macsmc-ioport alongside it, for the other machine types
<marcan>
and then in the rtkit case, that also builds on top of the RTKit helper library and talks to the hardware mailbox over the mailbox abstraction
<marcan>
macsmc-acpi instead would have ACPI shenanigans as the lower layer abstraction, etc.
<marcan>
the upper macsmc-* driver are always probed, but not all SMC instances in different machines would have all those features. they check to see if the relevant keys exist, if they do they probe, otherwise they ENODEV
<arnd>
ok, got it. I don't think I'll be able to remember all this, but I the bigger picture makes sense
<marcan>
so for example only M1s have GPIOs and handle the RTC through this (and those specific upper drivers have DT bindings which on x86 wouldn't exist), but macsmc-power is configless and I think should instantiate on T2 Macs too to provide nice battery stats there (possibly better than the ACPI ones)
<marcan>
there's also not yet done hwmon support that would be shared between all 3 machine types
<marcan>
and possibly other things
<marcan>
oh yeah, and macsmc-power won't probe on non-laptop M1s of course :)
linuxgemini9 has quit [Server closed connection]
<marcan>
since that's specifically battery/charging related (non-laptops do have power stats available, but those belong in hwmon)
linuxgemini9 has joined #asahi-dev
<arnd>
and it's the rtkit-helper (and below) that is shared with nvme and DCP, right?
<marcan>
yes (and the mailbox below it)
<marcan>
also tangential, but DCP actually talks to the SMC key-value interface over a backdoor mailbox, all on its own (the copro, not us) :)
<sven>
same for nvme, it also has a backdoor channel to SMC
<marcan>
yeah
<marcan>
one of the design decisions that went into RTKit was punting the specifics of how device addresses are mapped to the upper level driver, because it's just too variable
al3xtjames has quit [Server closed connection]
<marcan>
SMC uses a dedicated SRAM and does not have DMA access elsewhere, so no IOMMU
al3xtjames has joined #asahi-dev
turo has quit [Server closed connection]
turo has joined #asahi-dev
<marcan>
NVMe has that SART whitelist thing, plus the NVMMU which is not used for RTKit, mostly, except for some debug mode commands sven found which IIRC break that model
<sven>
yeah
<marcan>
while DCP uses an IOMMU for everything, including its own firmware mapped via the DAPF (which we normally don't even touch from linux), and that adds an offset to virtual addresses
<sven>
there are some vendor specific commands that all require SART for their buffers because they don't use the common PRPs thing
<sven>
for some reason macos tells ANS the current time during startup using one of those e.g.
<marcan>
so we actually have 1 addres space for SMC (physical only), but 3 for DCP (physical, IOVAs that the IOMMU maps, and DVAs used by RTKit/DCP stuff which is IOVA plus an offset in the top bits)
<marcan>
and that offset varies from device to device! M1 Max/Pro differ from M1 there
<marcan>
so since the specifics of mapping buffers and translating addresses differ from instance to instance, RTKit punts that to a callback back into the parent driver so it can do whatever it needs to do
<marcan>
e.g. the SMC driver just verifies that any addresses SMC gives us are in the expected (whitelisted) SRAM range, then does an ioremap
<marcan>
while others may actually allocate memory and return an appropriate DVA
<sven>
different co-processors also need a different way to hibernate them for suspend and/or reset. if you send them to the wrong power state they just won't come up again. and ofc that state differs between most of them
<marcan>
yeah, and also whether the AP or the copro allocates memory varies by copro and specific endpoint
<marcan>
either the copro says "give me a buffer this big" or "here's a buffer for you"
<marcan>
in the same context
<sven>
and DCP does both
<marcan>
yup
<marcan>
so since there's all this variability we pretty much need a bespoke interface between RTKit and whatever's on top
<marcan>
hence why we settled on implementing it as a helper library
<marcan>
that different parent drivers then configure as needed
<marcan>
there's also the fact that none of this is ever going to be useful outside these tightly coupled apple devices anyway
<marcan>
so there is no benefit in trying to shoehorn this into some standard subsystem
<marcan>
it'd just complicate everything with impedance mismatches
<marcan>
like mailbox already did but that's just because it's a crap design, it *could've* been done properly :)
<marcan>
but mailbox is a much simpler problem than the layer above RTKit
<sven>
even though you dislike mailbox so much I still think that is the correct place for the low-level HW stuff
<marcan>
oh I agree the idea makes sense
<marcan>
I'm just saying that subsystem design sucks :)
<marcan>
I'd fix it but I'd have to talk to everyone already (ab)using it and figure out what we do with that mess
<sven>
fair enough. I think it was find for the very basic single channel thing but I didn't bother with the atomic API there
<sven>
s/find/fine/
<marcan>
yeah, it got worse with the atomic api
<marcan>
which isn't even properly documented and different drivers/consumers interpret it differently
<marcan>
honestly the way it does queuing etc is just not a good match for how these mailboxes work on apple
<marcan>
that could be improved, but again, making sure not to break other consumers is always a pain
<marcan>
maybe one day I'll be bored enough to give it a shot
<sven>
yeah, the queuing doesn't fit well for the FIFO-backed mailboxes we have. but that could be fixed and IIRC the maintainer comment something like "no need to do this right now unless you have a good reason" back when I made that a better fit for v1
<sven>
*commented
<marcan>
yeah
<marcan>
if we're forced to do it it'll be if we find AGX needs it for performance
<arnd>
marcan: I completely agree with your description of the problems in the mailbox subsystem, don't have any good ideas for solving them either though
<marcan>
otherwise, when we get around to it :)
joske has quit [Remote host closed the connection]
<arnd>
I'm probably responsible for some of the early mistakes, but fundamentally we had (right from the start) people trying to fit very different hardware concepts into a single API
<arnd>
and then some drivers slipped in that completely ignored some of the decisions we had already made for the other drivers
msteffen has quit [Server closed connection]
msteffen has joined #asahi-dev
nametable[m] has quit [Server closed connection]
nametable[m] has joined #asahi-dev
<maz>
marcan: thanks for the braindump. it'd be good to have some if this rational as part of the cover letter or ML discussion, because IRC really isn't the right medium for that (or anything else IMO... ;-)
snnw[m] has quit [Server closed connection]
snnw[m] has joined #asahi-dev
<marcan>
maz: yeah, I should dump it in the ML, or maybe it can go in the cover for v2
pzcz has joined #asahi-dev
DarkShadow4444 has quit [Server closed connection]
RevHelix has quit [Server closed connection]
DarkShadow44 has joined #asahi-dev
pzcz has quit [Remote host closed the connection]
joske has joined #asahi-dev
kameks has quit [Ping timeout: 480 seconds]
yuyichao_ has quit [Ping timeout: 480 seconds]
roxfan has quit [Ping timeout: 480 seconds]
sjg1 has quit [Server closed connection]
sjg1 has joined #asahi-dev
yuyichao_ has joined #asahi-dev
Gaelan has quit [Server closed connection]
Gaelan has joined #asahi-dev
<joske>
marcan: the line with the bind mount (mount --bind "$ROOT" "$ROOT") ends up mounting /dev/nvme0n1p5 on /home/jos/Projects/asahi-alarm-builder/root type ext4
<joske>
on my system and then of course strange things happen
kov has quit [Server closed connection]
kov has joined #asahi-dev
<joske>
even when running manually "mount --bind root/ root/" this happens
Glanzmann has joined #asahi-dev
XeR has quit [Server closed connection]
XeR has joined #asahi-dev
<marcan>
joske: that is normal
<marcan>
that is how bind mounts work
<joske>
really??
<joske>
but it's mounting a folder on itself, not the / device??
<Glanzmann>
joske: Yep, that is a bind mount.
<joske>
mind == blown
<mps>
heh
<joske>
well in any case this mount step seems not necessary for manjaro, basestrap (their copy of pacstrap) doesn't seem to care about a mountpoint
kenzie35 has quit [Server closed connection]
kenzie35 has joined #asahi-dev
fortelling[m] has quit [Server closed connection]
fortelling[m] has joined #asahi-dev
jakebot has quit [Server closed connection]
jakebot has joined #asahi-dev
kode54 has quit [Server closed connection]
kode54 has joined #asahi-dev
bpye has quit [Server closed connection]
bpye has joined #asahi-dev
irth has quit [Server closed connection]
irth has joined #asahi-dev
nkaretnikov has quit [Server closed connection]
nkaretnikov has joined #asahi-dev
Emantor has quit [Server closed connection]
Emantor has joined #asahi-dev
axboe has quit [Server closed connection]
axboe has joined #asahi-dev
MZG[m] has quit [Server closed connection]
MZG[m] has joined #asahi-dev
nyx_o has quit [Server closed connection]
nyx_o has joined #asahi-dev
balrog has quit [Server closed connection]
balrog has joined #asahi-dev
ExeciN[m] has quit [Server closed connection]
ExeciN[m] has joined #asahi-dev
qiuren[m] has quit [Server closed connection]
qiuren[m] has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
roxfan has joined #asahi-dev
trouter has quit [Server closed connection]
trouter has joined #asahi-dev
yrlf has quit [Server closed connection]
yrlf has joined #asahi-dev
Simonx22 has quit [Server closed connection]
Simonx22 has joined #asahi-dev
winter has quit [Server closed connection]
winter has joined #asahi-dev
dumistaken[m] has joined #asahi-dev
ryan_nupp[m] has quit [Server closed connection]
ryan_nupp[m] has joined #asahi-dev
riker77 has quit [Server closed connection]
riker77 has joined #asahi-dev
phiologe has quit [Server closed connection]
Darkmatter66 has left #asahi-dev [#asahi-dev]
AntoniosPapadakis[m] has joined #asahi-dev
c10l2 has joined #asahi-dev
dabaiste^ has joined #asahi-dev
<marcan>
arnd: maz: I think you two need to have a battle over _relaxed ;)
<marcan>
(maz has made us default to _relaxed for everything except where required and now arnd is saying the opposite)
c10l has quit [Ping timeout: 480 seconds]
<maz>
marcan: we've had that battle for a long time, and I don't think we'll ever agree on that one.
<maz>
marcan: my point is that barriers are expensive, even on shiny HW like this one, and that *removing* barriers is incredibly hard. it also plays to the mindset of "I don't know what I'm doing, so I'll be adding barriers until it behaves".
<maz>
I'd rather people reason about what they are writing and use the right amount of synchronisation.
<maz>
and TBF, readin Arnd's emails, I mainly see the later.
<maz>
*documenting* why you use barriers or not is just as important as the barriers themselves (or lack thereof).
<alyssa>
Bug fix in the form of a passive aggressive patch, it's an art form :-p
Taro[m] has joined #asahi-dev
<alyssa>
Guessing there's a hw difference between the mini and the macbooks?
<Taro[m]>
As someone who has no experience with this type of stuff, where can I get started?
r0ni has joined #asahi-dev
nicolas17 has joined #asahi-dev
<jannau>
something heavy arrived and it is installing 5.27GB of updates
<j`ey>
:o
<jannau>
I could have skipped that but I see little sense in investigating a franken macos 12.2
<j`ey>
try not to fix too much, we want markan to stream it :P
<alyssa>
jannau: :-D
<alyssa>
j`ey: I heard he was going to stream that a bit more than a week from now
<alyssa>
super looking forward to it C:
<jannau>
I hope there's not much to fix. apple did claim ultrafusion is transparent to software so I assume Linux will just work ;)
<jannau>
if not I want my money back
<maz>
jannau: keep us posted! I hope to have my serial adapter ready by the time it lands (specially as I'm foolishly trying to write the firmware is bloody Rust...)
<maz>
in*
<jannau>
fans are noticeable running, still updating
<alyssa>
marcan: Which firmware?
<jannau>
and finished
<Glanzmann>
jannau: So just to confirm, you're serial uart has arrived?
<alyssa>
er, maz ^
<maz>
alyssa: firmware to drive the FUSB302 that enables the UART and allows me to remotely reboot the box. I already have one on the mini, but need a spare for the Studio. and since I can't get the same parts I used the first time, I'm redoing everything from scratch.
<j`ey>
whats driving it?
<maz>
basic m0, a stm32 knock-off that came as part of a USB-PD trigger.
<j`ey>
aha
<jannau>
Glanzmann: you mean my broken 3.6 kg heavy uart?
<Glanzmann>
jannau: Yep, that one. When you mentioned that there are updates for macos, I rebooted and searched for updates. None for me. But when you said ultrafusion, slowly I understood.
thasti has quit [Remote host closed the connection]
<jannau>
magic usb-c port is the one next to the ethernet port and reset still works
<tpw_rules>
you broke it already...?
the_lanetly_052 has quit [Ping timeout: 480 seconds]
thasti has joined #asahi-dev
<jannau>
no, just testing. I need the uart to see where where m1n1 dies on the first boot attempt
<maz>
jannau: cheers. saves me probing the other 5 ports! :D
<jannau>
installer works up to kmutil after removing the the obvious "not yet" comments
<jannau>
maz: second try was a success. I would have been surprised if it is not one of the outer ports on the backside
<jannau>
display init fails and then "assert(irq < 0x1000); // Will probably need updating for multi-die"
<Glanzmann>
Apropos dcp. I just rebased jannaus dcp branch on top of current asahi. If someone wants it: https://tg.st/u/dcp-2022-03-22.tar - all trivial
<marcan>
alyssa: does the HELD stuff still work the same?
<marcan>
I guess maybe 6 is "touch ID" and 1 is "power"?
<alyssa>
marcan: yes, HELD still works the same
<jannau>
it fails to find the framebuffer DVA, I have no proxy access yet since usb init fails
<marcan>
alyssa: also can you confirm if bHLD also works the same?
<alyssa>
marcan: bweh?
<alyssa>
(n.b. kernel is currently rebuilding with suspend support. cannot test kernel changes for 30 min until that finishes.)
<alyssa>
marcan: but looking at the code, I believe so
<jannau>
proxy over uart works including chainload
<j`ey>
alyssa: PCIe suspend doesnt work yet, unless you were looking at fixin thta
<j`ey>
*fixing that
<alyssa>
(otherwise the whole driver would refuse to load, clearly it does load since that patch works)
<alyssa>
j`ey: ...right
<Glanzmann>
jannau: Does it boot Linux?
<jannau>
usb phy init on the second die fails
<alyssa>
m1 ultra too chonk for m1n1 to handle
<jannau>
CPU cores have the m1 max MIDR part numbers, revision 0x20
learning_ has joined #asahi-dev
learning_ has quit []
<marcan>
alyssa: I mean whether you get the same values there when the button is pressed or not
* alyssa
confused puppy dog head tilt
<marcan>
like it's supposed to return the current button state when read
<marcan>
1/0
<marcan>
just want to make sure it's still 1/0
<marcan>
and not some bitfield
<alyssa>
I assume I need to go add printks to check that?
<marcan>
or I can just use smc.py on the mini
<marcan>
I'm just lazy
<marcan>
:p
<alyssa>
:p
<alyssa>
oh there it goes, it links
<alyssa>
let's see if it boots :-p
mnc7[m] has joined #asahi-dev
<marcan>
jannau: it's no fun if you do all the work before mine arrives :<
<alyssa>
suspend is wonky
<alyssa>
this is super cursed ok
<marcan>
alyssa: did you turn off pcie? :p
<marcan>
pcie will explode badly with suspend
<alyssa>
isn't suspending pcie disabled?
<sven>
jannau: atc-PHY has a more complete usb 2 phy init sequence as well fwiw
<sven>
erm, atc-WIP
<j`ey>
alyssa: nope
<marcan>
that's why we aren't shipping it yet
<j`ey>
I looked for about 5mins, but didn't find an obvious way to turn it off
<alyssa>
ah. right. yes.
<marcan>
I'm not entirely sure how one would disable suspend for pcie/brcmfmac to begin with
<alyssa>
what I'm actually interested in is DCP suspend+resume
<alyssa>
which ought to be easy, let's see
<j`ey>
I used initcall_blacklist=apple_pcie_init,apple_pcie_driver_init to stop pcie from being loaded (while testing suspend)
<jannau>
seems to be just missed ranges conversion
<alyssa>
nyeh
<alyssa>
does macOS suspend pcie?
m6wiq has quit []
<alyssa>
Well, I got suspend working, just nee to fix resume ;-p
rucadi[m] has joined #asahi-dev
<alyssa>
("Ah, so the same state as suspend/resume on most common linux machines")
<alyssa>
...and there we go, maybe, unclear TBD
<alyssa>
let me disable PCIe lol
<sven>
pcie resume probably “just” needs the phy init and tunables applied
<alyssa>
sven: ah.
<alyssa>
m1n1/src/pcie.c except in the kernel?
<j`ey>
sven: it already crashes at the suspend step
<sven>
oh, suspend already fails?
<sven>
then it’s a bigger issue I guess
<alyssa>
womp
<j`ey>
I don't have the logs currently, but something something d3
<sven>
alyssa: just guessing, but atcphy loses all tunables if I power it down in pmgr
<sven>
so I’d assume it’s the same for pcie but who knows
<kettenis>
I did some experimentation at the time I wrote that m1n1 code
<kettenis>
and disabling the "clocks" did not make the hardware lose the "tunables"
<sven>
looks like kettenis knows :-)
<kettenis>
but that was before we realized the clocks were actually power domains
<sven>
ah, that’s something in the wifi driver I think
<alyssa>
what if we disable wifi?
<sven>
who needs WiFi anyway ;)
<j`ey>
o/
kita99 has joined #asahi-dev
m6wiq has joined #asahi-dev
<alyssa>
me: i should work on panfrost
<alyssa>
me: i should work on agx
<alyssa>
also me: *works on DCP inexplicably*
<sven>
tasked failed successfully 🤷🏻♂️
<sven>
*task
<nicolas17>
me playing around with a DCP wireshark dissector while having a hundred other things to do
<alyssa>
ah well yes
PaterTemporalis has quit [Ping timeout: 480 seconds]
<alyssa>
writing DCP code blind is sane right?
<alyssa>
...right?
<alyssa>
it'll probably work out right
zoey has joined #asahi-dev
<alyssa>
Hmm the last thing I see in dmesg is "PM: suspend entry (s2idle)"
<alyssa>
doesn't seem to even *try* to wake up now, uh
<alyssa>
or /var/log isn't flushing, also possible.
<j`ey>
I also have no_console_suspend
<alyssa>
what's that do?
<j`ey>
I think its meant to keep the console alive, to get more messages out during suspend
zoey is now known as Guest48
<alyssa>
i think it bork
<alyssa>
it do seem to have done a bork
<alyssa>
I probably need the hv to debug this.
<alyssa>
Too much work. Should get back to userspace where I belong.
<alyssa>
I don't like being pigeonholed out of kernel but maybe it's for the best
Guest48 has quit [Quit: Page closed]
<alyssa>
ah ha there we go
<jannau>
it's probably pmgr. clock/power gates have a die id in the most significant nibble. there's just a single pmgr instance which looks identical to a single m1 max
<alyssa>
um
<alyssa>
good news, got DCP on and off
<alyssa>
bad news, kernel is seriously borked I think
<alyssa>
but no evidence thereof, gah
joske has quit [Remote host closed the connection]
<alyssa>
I think this does what we want, but with so many other issues with suspend/resume on these machines it's honestly hard to know
<jannau>
alyssa: looks like a good first step for s2idle. I wonder if macos also suspends dcp via rtkit
<alyssa>
that patch at minimum gets the video to stop ("no signal" on my display) and then come back after
<alyssa>
whether it's correct is hard to tell with so much other suspend-related breakage
<jannau>
I'll queue the patch. I think it is correct but it might not be complete
<alyssa>
*nod*
<alyssa>
One step closer to proper s2idle at least
<nicolas17>
idk if this wireshark thing is useful but at least it got my executive functioning un-stuck yesterday
<jannau>
display breakage is caused by iboot not mapping the framebuffer
<kettenis>
so it is even more broken than on the mini?
Darktux has joined #asahi-dev
<jannau>
maybe, why should it map the framebuffer for dcp/disp0 if it doesn't init the devices
m6wiq has quit []
Darktux has quit [Quit: Konversation terminated!]
Darktux has joined #asahi-dev
Darktux has quit []
kelito has joined #asahi-dev
<jannau>
display works after mapping vram
<jannau>
allocated vram is just large enough for 1920x1137 at 32bpp
kelito has quit [Quit: Konversation terminated!]
<Glanzmann>
jannau: Is that for the studio or also other models?
<jannau>
that's for studio, I haven't looked on the m1n1 under macos 12.3 yet
<Glanzmann>
I see. But since I'm running a bigger resolution right now, I probably already have the answer. :-)
<jannau>
yes, I think so too, otherwise you shouldn't have seen just 1/4 on the 4k tv
<jannau>
Glanzmann: on the mini vram can fit 5.5 million pixels, would be good for 3440x1600 or 3840x1433 at 32bpp
Candygoblen123[m] has joined #asahi-dev
<alyssa>
jannau: why does preallocated vram matter if m1n1 speaks DCP..?
kelito has joined #asahi-dev
kelito has quit [Remote host closed the connection]
efegurkan[m] has joined #asahi-dev
pzcz has joined #asahi-dev
pzcz has quit [Remote host closed the connection]
badlydrawnface[m] has joined #asahi-dev
<AntoniosPapadakis[m]>
I'm interested in helping out the Asahi Linux development in my free time. I obviously have some hardware that I can use to test. Where should I start? Thank you all.