chadmed has quit [Remote host closed the connection]
Dcow has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jannau has quit [Ping timeout: 480 seconds]
_jannau_ has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-dev
Dcow__ has quit [Ping timeout: 480 seconds]
jannau has joined #asahi-dev
_jannau_ has joined #asahi-dev
gladiac is now known as Guest8685
gladiac has joined #asahi-dev
Guest8685 has quit [Ping timeout: 480 seconds]
Dcow_ has joined #asahi-dev
chadmed has joined #asahi-dev
<sven>
tpw_rules: Huh, why do you think it was removed?
<sven>
and that file is pretty much the only documentation
<sven>
it’s more recent than what’s in m1n1 as well fwiw
coder_kalyan has joined #asahi-dev
Dcow_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-dev
Dcow_ has joined #asahi-dev
<kettenis>
sven: I'm probably going to look at adding the code to (re-)start the coprocessors in OpenBSD this weekend
<kettenis>
then I can shut them down in U-Boot
<sven>
let me know if you have any questions, I’ve done that in that “new” nvme driver there. And also
<sven>
*and also please figure out how to reset them no matter which state they’re in ;)
<kettenis>
mwahaha
aleasto has joined #asahi-dev
<sven>
fwiw, that thing doesn’t support the admin abort command. I’ll remove that one from the Linux driver as well
<kettenis>
looks like u-boot doesn't use the abort command
<kettenis>
does the nvme/dev branch reflect your latest understanding of the rtkit stuff?
Dcow_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
as400[m] has joined #asahi-dev
Dcow_ has joined #asahi-dev
Dcow_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sven>
Pretty much
<sven>
i can push my local branch later today
<sven>
but I think that one only has changes to the nvme part
Dcow_ has joined #asahi-dev
Dcow_ has quit []
<sven>
just pushed what i have locally
chadmed has quit [Ping timeout: 480 seconds]
<tpw_rules>
sven: ah hm, i guess that commit was never merged? i feel like that is new
<tpw_rules>
kettenis: did you already have code to shut them down in u-boot in some other branch? i worked on it a bit last night but haven't got it working yet
<kettenis>
nope
<kettenis>
I think the nvme driver will need a .remove method
<kettenis>
but a quick test shows that that doesn't get called
<tpw_rules>
but the processors did not seem to be responding to my messages to shut them down. i was a bit suspicious that u-boot left them in a bad state starting up.
<sven>
tpw_rules: yes, that code is newer than what's in the main branch
<tpw_rules>
sven: ah ok, i got confused because i saw a commit with the same name that was more recent
<kettenis>
tpw_rules: it leaves the device in a usable state; nvme works fine in OpenBSD this way
<tpw_rules>
kettenis: yeah the drive does work, but it seems the processors are confused. i altered how u-boot started them slightly and then the processors at least replied to my shutdown messages, but linux still couldn't start them back up properly. ah well, i will get back to it in a few hours
<sven>
you need the "new" code to start them back up
<sven>
or at least set that reset bit in the PMGR regs
<tpw_rules>
by the way, do all the macbook keyboards work in u-boot in the apple-m1-m1n1-nvme branch
<marcan>
leaving them running isn't really valid anyway without some kind of handoff mechanism for the SART buffers
<kettenis>
currently u-boot reserves the memory for the SART buffers in the EFI memory map
<kettenis>
so that part is "safe"
<kettenis>
of course it means that the OS has no access to the logs
<kettenis>
which is not ideal
<kettenis>
tpw_rules: only usb keyboards work in u-boot
<marcan>
kettenis: if it decides to log without getting its locks acked it well might deadlock
<kettenis>
so none of the laptop keyboards do
<sven>
it'll deadlock once rtkit's syslog ring buffer is full
<marcan>
so definitely not safe
<sven>
and if you do large transfers it's going to send some "new WhateverBuffer %d" created messages
<kettenis>
nvme doesn't seem to do any logging though (but SMC does)
<sven>
nvme *does* some logging, but only if you saturate the link for a while
<kettenis>
anyway, I agree, this needs to be fixed
<sven>
(also if you send invalid commands)
<kettenis>
which is why I didn't try to upstream the NVMe stuff yet
nabaiste^ has quit [Remote host closed the connection]
<sven>
i should fix the error recovery and submit a RFC as well
<tpw_rules>
kettenis: ah ok, i saw some work on the spi drivers so i wasn't sure
kgarrington has joined #asahi-dev
kgarrington has quit [Remote host closed the connection]
Dcow_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zimsneexh has joined #asahi-dev
Dcow_ has joined #asahi-dev
Dcow_ has quit []
Dcow_ has joined #asahi-dev
yuyichao_ has quit [Quit: Konversation terminated!]
m42uko has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi-dev
<tpw_rules>
what is the apple device tree name of the ASC responsible for the nvme drive?
<marcan>
ans
<j`ey>
(which is what it's also called in the linux dt)
<j`ey>
ans: mbox@277408000 and ans2: nvme@27bcc0000
<marcan>
(and those labels are weird, should probably just be ans_mbox for the first)
<marcan>
(ans2 is the version AIUI, so that one makes sense)
<kettenis>
that's what sven has in his tree
<sven>
The kext and ioreg calls it ANS3 fwiw
<sven>
And I think in my current tree they’re called ans_mailbox and ans
<sven>
that old tree had a big “WIP” and “DO NOT MERGE” in the device tree commit that you people all just ignore :p
<j`ey>
sven: DO NOT MERGE (into mainline) is how I read it :P
<kettenis>
the nvme node doesn't need a label as far as I can tell
<marcan>
I think we've been kind of labeling everything out of inertia, but yeah, I don't see us doing anything with that one
kilrain[m] has joined #asahi-dev
yuyichao_ has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
<conradev>
Does anyone know how this raw image change will affect the installation flow? Does this give any insight into what materials are needed on a partition to convince Apple to boot it, or is it orthogonal?
<conradev>
Does anyone know how this raw image change will affect the installation flow? Does this give any insight into what materials are needed on a partition to convince the bootloader to boot it, or is it orthogonal?
<kettenis>
yes
aleasto has quit [Remote host closed the connection]
<alyssa>
marcan: sven: relatedly - Is it theoretically possible to run (a clone of) kmutil under Linux, after security has been downgraded in 1TR?
<alyssa>
Or does the security model prevent that?
<sven>
what use case do you have in mine for that?
<sven>
we we certainly can't do is upgrade and/or change the m1n1/uboot payload from linux
<sven>
*what we
<alyssa>
sven: ^ that
<sven>
yeah, not gonna happen
<sven>
the security model requires assertion of physical presence to update the boot object (i.e. long-press the power button to go into 1TR)
<alyssa>
on e.g. chromebooks with their funny boot model, once security is downgraded you can reflash the machine live with dd to the right partition
<alyssa>
wasn't sure how Apple had things set up
<sven>
yeah, apple has a stronger model
<ChaosPrincess>
what happens if you bless a mach-o with kmutil, and then overwrite that file on disk?
<sven>
configure-boot talks to SEPOS and requests it to include the boot object's hash into this local policy thing and then sign that
<sven>
but SEPOS will only do that if the machine is in 1TR
<alyssa>
sven: How do macOS kernel upgrade work?
<alyssa>
Apple has a private key backdoor to this? or the installer reboots into 1TR?
<sven>
don't know the details but they can sign the kernel with their key
<alyssa>
How dreadfully boring :-p
<sven>
it'll also ask for your password during the update because SEPOS will have to re-encrypt anything that was encrypted with a key derived from the old firmware with the key derived from the new firmware
<alyssa>
Huh, neat
<alyssa>
Apple takes this seriously :)
<sven>
yeah
<sven>
there's a security whitepaper from them somewhere that superficially explains all that
<sven>
this entire design is pretty great :-)
<ChaosPrincess>
so its kinda like secureboot + mok(if permissive security) + disk encryption via tpm tied to firmware and kernel hashes?
<sven>
hrm... now that i think about it again, i think you can actually install custom kexts without taking a detour through 1TR after security has been downgraded once
<ChaosPrincess>
sven: so, thats not quite how kmutil works apparently. if you do configure-boot, it will stash the new boot object _somewhere_, and you can freely overwrite the old file, it no longer matters
<sven>
uh, yes?
<kettenis>
if you follow the instructions, you download the file to a ramdisk
<kettenis>
so it will be gone after you reboot
<ChaosPrincess>
following the instructions is for those who dont want to spend a few hours trying to understand why edits to the initrd dont seem to work :P
Dcow_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<tpw_rules>
kettenis: i an convinced at this point u-boot is not properly starting the ANS ASC, despite the fact that the drive works. see the logs here: https://pastebin.com/qdXKfVhZ . u-boot does not do most of the transactions on endpoint 4, never gets the final 0xb message on the management endpoint, and never gets any log messages
<tpw_rules>
i have a feeling it's not happy with the memory addresses it's given. it's not obvious to me how linux allocates the memory it hands out, and it doesn't seem to touch those MMIO registers at 0x2774000xx
<sven>
pretty sure there's something wrong with the device tree you're using for u-boot
<sven>
it looks like it's trying to configure SART at 0x277400000 while that should actually be at 0x27bc50000
<tpw_rules>
yeah i just had that realization too. but the nvme's sart in the device tree is at 0x27bc50000 . so maybe u-boot is loading it wrong
<tpw_rules>
and it was never noticed since the drive still works...
<sven>
no, that makes no sense
<tpw_rules>
what doesn't?
<sven>
what you just said
<sven>
keep in mind that the device tree for u-boot and linux probably still looks a bit different at this point
<sven>
specifically for drivers like sart/nvme that haven't been upstreamed yet
<tpw_rules>
this is the relevant part of the u-boot device tree: https://pastebin.com/Vzyv2B6S it's the same as the linux one, except the phandles are different naturally
<sven>
unless apple changed something in the ANS firmware the nvme layer will not come up before at least crashlog and syslog have been initialised successfully
<tpw_rules>
i see that 0x277400000 pointer in the nvme's registers, do you expect that to point to the sart?
<sven>
yes
<jannau>
u-boot device tree should not be used. use u-boot-nodtb.bin
<sven>
i'm not too familiar with u-boot but i know that it used to receive syslog messages
<tpw_rules>
so that line should be reg = <0x02 0x7bcc0000 0x00 0x40000 0x02 0x7bc50000 0x00 0x10000>; ? i'm not so sure
<sven>
what makes you think that?
<tpw_rules>
well a) because it's how it is in that pastebin in the linux kernel device tree which works and b) i would expect it to read the address of the sart registers from the linked sart node
<sven>
that's certainly not how it's in the linux device tree
<sven>
and the sart node should be reg = <0x2 0x7bc50000 0x0 0x10000>;
<sven>
but i don't know if u-boot uses the same bindings
<tpw_rules>
okay, so then the device tree is correct, i just explained it wrong
<tpw_rules>
then yes, i'm pretty sure u-boot copied over the linux device tree, the semantics changed, but no one noticed because the drive still initialized enough to be readable
<sven>
that sounds weird
<sven>
as i said, i very much remember trying to get away with as little initialization as possible
<sven>
and it wasn't possible to bring up nvme without rtkit being up as well
<sven>
now that could've changed if apple changed the ANS firmware but it would surprise me
<kettenis>
well, what can I say, this works for me on two machines
<kettenis>
I can access the nvme disk from u-boot and I can use it as the root disk for OpenBSD
<kettenis>
both machines have macOS 11.x firmware though
<sven>
my money is still on some issue with the device tree. that hypervisor trace very much looks like u-boot for some reason thinks SART is 0x277400000. and i know it didn't use to think that because it also worked for me
<kettenis>
and I synced up the device tree with the asahi linux branch just a few days ago
<kettenis>
reg = <0x2 0x7bc50000 0x0 0x10000>;
<sven>
yeah, i dunno what's going on with tpw_rules's machine either
<tpw_rules>
though the actual problem doesn't appear to be fixed yet
roxfan has quit [Remote host closed the connection]
roxfan has joined #asahi-dev
m42uko has joined #asahi-dev
<kettenis>
now how did that ever work?
<sven>
maybe you accidentally did find a way to boot ANS without booting RTKit completely
<sven>
but i'm still not sure how that could ever work. it should hang once nvme is brought up because it will try to write to the syslog at that point
<tpw_rules>
i mean it does by all accounts hang. it's just that that doesn't seem to matter too much somehow
<sven>
yeah, but nvme should also hang in that state
<tpw_rules>
not really knowing any of the context, maybe the nvme still works if the IOP is okay but the AP is not?
<sven>
uh, i'm confused now
<sven>
IOP = the thing RTKit runs on
<sven>
and that thing should hang if SART isn't configured correctly
<kettenis>
as long as it doesn't log, it should be ok
<tpw_rules>
then what is the AP?
<kettenis>
and I've not seen it log
<sven>
okay, that's very strange then
<tpw_rules>
it seems to always print out stuff about garbage collection when linux starts it
<sven>
because it definitely logs when the admin queue is brought up
<kettenis>
both the u-boot and the OpenBSD driver still have some magic writes inherited from the corellium driver
<j`ey>
tpw_rules: ap = application processor, main cpu
<kettenis>
so maybe those are relevant here...
<sven>
those weird 0x102/0x1002 writes?
pavellatko[m] has joined #asahi-dev
<sven>
i haven't observed any difference without those fwiw
<tpw_rules>
j`ey: i mean my conception, driven purely by the names of the relevant messages, is that each thing that runs rtkit has both an IOP and an AP. is that true?
<sven>
tpw_rules: AP = that thing that runs linux/openbsd/u-boot/..., IOP = that thing which runs RTKit
<kettenis>
sven, yes
<tpw_rules>
sven: so there are a bunch of IOPs and one AP (of several cores)? i'm a little confused about what the SET_AP_PWR_STATE message is for then
<sven>
ask apple about that one. the name comes from a string RTKit sends over syslog when you use that message with an invalid power state
<tpw_rules>
ok
<sven>
maybe it's more like "report AP power state"
pavellatko[m] is now known as latko[m]
<kettenis>
pushed the fix; thanks tpw_rules for spotting that
<sven>
hrm, so even with those 0x102/0x1002 writes it still tries to write to the syslog. i'm still confused how that ever worked
<tpw_rules>
i'm pretty sure there is still something wrong as the trace hasn't changed
<tpw_rules>
i did change a few other miscellaneous things to make the trace look more like linux's. but if/when i get all this working i'll send you a patch
<sven>
fwiw, the trace doesn't have to look exactly identical
<sven>
the different endpoints on RTKit (syslog, crashlog, etc.) are running in different threads
<tpw_rules>
it's actual content issues, not just ordering
<kettenis>
I'm fairly confident that I do see a 0xb message for the SMC but don't see one for ANS
<sven>
hm.... that's strange
<sven>
because i'm pretty sure i see one for ANS
<tpw_rules>
what exactly does the IOReporting endpoint talk about?
<sven>
let me know once you figure it out :-)
<kettenis>
zzz time here; going to take a closer look at this from the OpenBSD side tomorrow