00:01 <alyssa> sven: So if I get rid of the "link up wait" poll entirely, PCIe still comes up fine.

00:01 <alyssa> (Like without handling interrupt either)

00:03 <alyssa> what's unclear to me is if that's valid or if we're just winning the race every time.

00:14 <alyssa> similarly for the link idle poll, just checking once before the init is a lot simpler. but again, now I dunno if there's a race.

00:15 <alyssa> (It's worked every single time I've booted, but that isn't proof of the absence.)

02:48 <alyssa> sven: For whatever it's worth, "irqchip/apple-aic: fix irq_disable from within irq handlers" and "arm64: apple: add dwc3 controller and DART nodes" are both

02:49 <alyssa> Reviewed-and-tested-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>

02:50 <alyssa> would love to get the dwc3 one out of my tree, it's been at the center of so many conflicts...

06:04 <sven> alyssa: pretty sure we just win the race

06:04 <sven> and we need the interrupt for thunderbolt in the end anyway

06:05 <sven> alyssa: the apple-aic is on the ML and needs marcan's review/ack. and i'd rather wait before submitting the usb nodes until at least the replugging issue is fixed

06:07 <sven> and regarding conflicts... that's probably because i didn't order the nodes correctly. if they're all order by address git should be able to just resolve them

06:07 <sven> *ordered

06:50 <marcan> I'll look at it tomorrow, wrapping up some other stuff today

06:50 <sven> no worries, it's not required for pcie. you also only hit that issue if you disable an interrupt inside its own interrupt handler, so it's probably rare

06:52 <pipcet[m]> (not that rare, but it's a pretty obvious fix)

09:51 <landscape15[m]> Hi. Do you think FileVault encryption will not be a problem for Asahi to run? I don't want to reduce security.

10:00 <MTecknology> IIRC, that's currently not recommended; I think it's mentioned in the "how to" docs

10:00 <tophevich[m]> landscape15: Without realy answering your question directly, AFAIK nobody would recommend Asahi for production use in any way, shape or form at the moment. You can use it for testing/hacking purposes with the explicit knowledge that it can break things, like currupt your drive.

10:01 <pipcet[m]> (which might require a DFU recovery!)

10:02 <MTecknology> Is that the "revive" method?

10:03 <pipcet[m]> I believe it is, yes.

10:04 <landscape15[m]> Ok thanks. I can't understand why macOS Recovery isn't built-in. It would be better also for Apple 🙂

10:04 <MTecknology> Ehm, as a mac hater, I'd say they do a pretty good job of it

10:05 <MTecknology> With the dual boot method, my brain can't currently see any way to brick it

10:06 <sven> DFU is only required if you mess up very badly, like using a nvme-enabled kernel and then overwriting the entire namespace or something

10:06 <MTecknology> I would need a friend of a friend with a mac to be able to use that recovery option, but I'm sure I could find /someone/.

10:06 <sven> there's also a chance that erasing the NOR flash bricks it even beyond DFU-repair, but that's still unknown

10:06 <pipcet[m]> sven: writing to the recovery partition does the trick :-)

10:06 <sven> libidevicerestore also support DFU-restore now afaik

10:07 <sven> so all you should need is another linux machine

10:07 <MTecknology> oh, neat-o

10:07 <sven> there's at least a PR that got merged so i assume it works :-)

10:08 <MTecknology> "libidevicerestore" currently goes over my head and I start a new job in a few hours so I /should/ go to sleep, but I made a note of that for later reading.

10:08 <sven> https://github.com/libimobiledevice/idevicerestore

10:08 <landscape15[m]> MTecknology: Yeah, I'm also pleased that the T2 chip has been removed.

10:09 <MTecknology> Thanks :)

10:09 <sven> might be more accurate to say that the intel chip got removed and the T2 chip was improved :D

10:15 <chadmed> yeah the T2 didnt go anywhere, its just been renamed to the SEP

10:15 <sven> uh, no

10:15 <sven> the T2 became the main SoC

10:15 <sven> the T2 also has an SEP afaik

10:16 <landscape15[m]> Maybe the Touch ID data is saved there

10:16 <sven> what used to be the T2 is literally the M1 now

10:17 <chadmed> yeah wow ok errors have been made

10:17 <chadmed> never realised it was so... fully featured

10:18 <sven> yeah, i'm pretty sure you could even run linux with the various patches for M1 support on the T2 with some minor changes

10:18 <landscape15[m]> I hope, because I have a T2 Mac right now.

10:19 <sven> erm.. that wouldn't help you there

10:19 <pipcet[m]> sven: you haven't run into the nGnRnE/nGnRE thing at all so far, right?

10:19 <sven> pipcet[m]: what do you mean by that?

10:20 <pipcet[m]> (weird serrors when mixing read and write accesses to mmio space)

10:20 <sven> uhh... no

10:20 <sven> and it sounds like you're doing something weird

10:20 <landscape15[m]> sven: But I think I will definitely forget Intel Macs in few years...

10:22 <pipcet[m]> sven: corellium code (which uses nGnRnE) works, asahi doesn't, asahi + ioremap_np works again, pretty sure it's the E/nE thing. only shows up in kernel code since you have to mix read*() and write*() pretty much immediately for it to race

10:23 <sven> yeah, as i said: doing something weird

10:24 <pipcet[m]> I was writing to the SMC SRAM and it behaved like the writes never happened, so I added some reads to make sure they made it, and they didn't...

10:24 <tophevich[m]> https://twitter.com/marcan42/status/1423214292145299457

10:27 <marcan> pipcet[m]: the initial patchset introduced ioremap_np into the relevant abstraction layers

10:27 <marcan> it's not a race. if you use the wrong mode you get SErrors on writes, period, always

10:27 <marcan> (if you're not corellium and don't disable it :p)

10:28 <marcan> M1-specific drivers that need to do bare ioremaps on non-PCI space and cannot just rely on the existing abstraction layers for openfirmware/etc should use ioremap_np

10:28 <pipcet[m]> so IIUC they disabled the serrors and wrote in the wrong mode, and you didn't and write in the right mode? cool.

10:28 <marcan> I don't know why they disable the serrors

10:28 <marcan> I do know you can get serrors for other reasons, e.g. byte writes to the UART, but those *do* work even though you get a serror

10:29 <marcan> so I can only assume they have semi broken drivers that trigger errors but still (kind of?) work and that's why they do that

10:30 <kettenis_> yeah the uart writes were fun ;)

10:30 <marcan> also corellium did the ioremap stuff in a completely different way, so if you're grafting their drivers onto mainline, that won't work if they use ioremap directly

10:30 <marcan> you need to go through the appropriate abstraction layers or use ioremap_np

10:31 <marcan> this is why I spent weeks bikeshedding this to find a solution acceptable to mainline ;)

10:33 <pipcet[m]> fair enough

10:35 <marcan> anyway, just to reiterate: I know a bunch of the corellium code is bad, and y'all are taking those drivers as-is under your own responsibility. I'm going to take a good look at getting this kernel mess on track starting this week, just let me wrap up some unrelated stuff today ;)

10:36 <landscape15[m]> I tried the Corellium project, but it is almost unusable. I hope Asahi will be as clean as possible, especially with GPU drivers.

10:37 <marcan> that is the goal :)

10:37 <marcan> it just takes some time

10:38 <landscape15[m]> Ok then ;) Rome has not been built in one day

10:43 <landscape15[m]> Which community should I look when watching the Youtube streams?

10:44 <j_ey> landscape15[m]: here or the youtube chat

10:45 <marcan> I generally have both open

10:45 <landscape15[m]> Ok thanks, I will keep both opened

10:46 <marcan> also if you're saying something to me here, ping me by name, since it's not a channel dedicated to the stream

10:47 <tophevich[m]> marcan: it feels spammy in here, and it is quite disconnected if ppl don't know that one writes in response to something happening on stream, #asahi-streams or something along those lines would might be nice. Can also be used by others while like alyssa ...

10:47 <marcan> yeah, that might be a good idea

10:47 <landscape15[m]> marcan: Yes sure

10:51 <tophevich[m]> (omg, my sentences always get so jumbled, I'm a realy bad multi-tasker, but I keep trying and failing at it anyways ... I hate that it gives the sence of being oh so productive while in reality it is quite the opposite :( ... sorry in advance if you feel like you are having a stroke while reading my word salat)

11:02 <jn> good idea. the /topic of #asahi-stream could also have the link to the currently running stream, while there is one

11:15 <marcan> sounds good, I'll set it up before the next stream :)

13:37 <alyssa> sven: ack.

19:49 <jeffmiw> fwiw I just updated the https://github.com/AsahiLinux/docs/wiki/SW:Hypervisor wiki page with some details about macOS & Kernel version as it can help when trying to reproduce the experiment(booting macOS under hv). I did validate it with macOS 11.5.2.

22:37 <alyssa> Two years of Mali r/e have made me way too comfortable writing drivers I don't understand for hardware I don't understand.

22:39 <JTL> :D