10:22 <amw> marcan: Do you know what's required to get the keyboard going?

10:23 <amw> The USB drive to run the M1 off is compact but the keyboard is annoyingly large

10:26 <sven> SPI controller (iirc also based on something linux already has a driver for) + platform backend for the already existing driver

10:30 <sven> oh, and probably gpio/pinctrl to make SPI work in the first place

10:35 <amw> ok - so we don't need those pesky dart/ASC thingies - Yeah!

10:36 <sven> that reminds me.. i should submit v5 of the dart driver

10:36 <pipcet[m]> amw: I can answer questions about the corellium driver if that would help (and you don't want to look at it yourself)

10:38 <sven> their platform backend for the keyboard driver is probably a good start. might even already be upstreamable directly

10:40 <amw> pipcet[m]:That would be nice. If it doesn't compromise my ability to make PRs I would be happy to look at it.

10:43 <pipcet[m]> amw: best ask marcan about that, I don't want to do anything to ruin the PR-ability of anyone's changes :-)

10:43 <amw> ok - thanks - will do

12:17 <kettenis> the keyboard is allegedly the same as what is used in the most recent Intel Macs and does indeed use an SPI interface

12:17 <kettenis> on Intel Macs there is some sort of ACPI abstraction for the SPI controller though

12:18 <kettenis> so that will require a new driver of some sort

12:18 <kettenis> shouldn't be too complex though

12:47 <pipcet[m]> a complete driver is fairly complex, I'd say: you need to mux the pins to the SPI interface, write a driver for the SPI chip, write a driver for the second GPIO chip so you can receive interrupts from the keyboard, and then you need to adjust applespi to handle real SPI rather than ACPI. (Just maybe you can get away with setting the pins to GPIO and bit-banging SPI over it, but that's really only good enough for boot loaders.)

12:48 <kettenis> true

12:48 <pipcet[m]> oh, and probably rely on m1n1 to bring up the clocks.

12:48 <kettenis> or u-boot ;)

12:48 <_jannau_> I see I need to stop slacking off on the pinctrl driver

12:51 <kettenis> should be possible to implement pinctrl using mostly generic code

13:00 <pipcet[m]> also some of it might be set up the right way already, but relying on Apple to keep things sane seems a problematic bet at best.

13:04 <amw> Would the linux/drivers/input/keyboard/applespi.c be relevant?

13:04 <pipcet[m]> very much so :-)

13:16 <alyssa> amw: I believe the rule is if you look at corellium code, tell sven but don't tell marcan 😋

13:17 <kettenis> hah

13:18 <alyssa> kettenis: corellium didn't do DCP/AGX code so I'm clear 🙃

13:36 <pipcet[m]> alyssa: btw, I'm playing around with the DCP stuff a little, but so far all I've found out is (1) the DCP doesn't like it if you fail to initialize the shared memory area to zero before giving it access (2) the magic numbers for setting the backlight brightness are "A352", 15, and 0x20d0000

13:53 <alyssa> fun :)

18:37 <marcan> alyssa: I literally looked at corellium code on my stream the other day, where did this myth come from? >_>

18:38 <marcan> pipcet[m]: those magic numbers are for what DCP firmware version? because as I said, the ABI is not stable, not even the call numbers

18:38 <marcan> (which is yet another reason why we won't and cannot dual-boot within a single OS container :p)

18:39 <marcan> but you probably mean this: https://github.com/AsahiLinux/m1n1/blob/63e8d0d48e5885c20e0a937546ea0af5b2083741/proxyclient/hv/trace_dcp.py#L219

18:53 <alyssa> marcan: "where did this myth come from?" probably twitter

18:53 <alyssa> or me and sven conspiring

18:53 <alyssa> or me and sven conspiring on twitter?

18:54 <marcan> that sounds about right

18:58 <alyssa> sven: 😈

19:00 <alyssa> marcan: "A443": "IOMobileFramebufferAP::printRegs()",

19:00 <alyssa> ^ That seems super interesting, have you tried that?

19:00 <marcan> I have not!

19:01 <marcan> A443 = Call(int_, "do_create_default_frame_buffer")

19:01 <marcan> remember what I said about unstable ABI?

19:02 <alyssa> Groan

19:02 <jix> how does that work when you have different mac os versions installed?

19:02 <j_ey> the firmware is per-boot

19:03 <j_ey> I mean, per partition

19:03 <alyssa> j_ey: that's a relief.

19:03 <jix> ah, so at least it doesn't randomly change for linux then when you update mac os on another partition...

19:03 <marcan> yes

19:04 <marcan> this is why I'm going to declare certain macos versions (i.e. firmware bundles) golden for linux

19:04 <marcan> and we will only support those

19:04 <j_ey> marcan: I wonder if the DCP firmware and macos are in the same repo, or at least some shared headers

19:04 <alyssa> almost certainly.

19:04 <j_ey> (just out of curiosity)

19:04 <marcan> I'm pretty sure they have some generator thing for the IPC

19:04 <marcan> similar to what we'll do

19:04 <alyssa> yeah

19:05 <alyssa> marcan: I'm also wondering, like

19:05 <alyssa> you joke about splitting a driver down the middle and putting half on each processor

19:05 <alyssa> is it possible they literally have a single driver src tree and it's just compiled for heterogenous processor etc?

19:06 <marcan> alyssa: printRegs does... nothing

19:06 <alyssa> hm.

19:06 <marcan> and nah I don't think they're that smart

19:06 <marcan> but they do obviously share code

19:06 <marcan> probably via copy and paste :p

19:06 <alyssa> Pff

19:07 <marcan> it's A444 on 12.0-beta3 fwiw

19:08 <marcan> so poll: should I spend some time writing an install script so we can actually switch versions without doing a full macos install, and without a gian partition and waiting for an hour?

19:08 <marcan> or should I keep that on the stack and go straight to working on AGX?

19:08 <j_ey> I mean, the choice is obvious for me :P

19:09 <alyssa> i am admittedly biased towards getting to try out my 3d drivers on linux ;p

19:09 <marcan> have you verified that they work after updating macos btw? maybe some of the stuff you have to deal with in userspace is also firmware-dependent :p

19:09 <alyssa> hnnnngh

19:10 <alyssa> it worked between two versions within 11.x ...

19:10 <kettenis> the benefit of #1 could be that more people start hacking on Linux kernel code

19:10 <marcan> time to put on 12.0-betaX!

19:10 <marcan> since you'll need that for DCP anyway

19:10 <marcan> :p

19:10 <alyssa> marcan: thanks for volunteering to test ahead of time

19:10 <kettenis> but I'm not sure if that will really be the case

19:11 <marcan> well, I don't think writing an installer should take *that* long, unless I hit a showstopper, in which case I could shelve it and come back later

19:11 <marcan> main thing I need to verify is that you *can* use machine owner credentials from another installed OS for bputil/kmutil, I'm not entirely sure about that yet

19:11 <alyssa> kettenis: as much of a PITA the macos dual install is, it's far more newbie friendly than linux kernel hacking :(

19:11 <marcan> if you can't that kind of breaks my current idea

19:11 <j_ey> marcan: prototype installer to test assumption, then AGX >:D

19:12 <marcan> sure :p

19:12 <marcan> also if anyone knows of a portable python3 bundle thingy I can just download and run on macos/arm64, that would be helpful, since I'd much rather write this in python than, uh, shellscripts and C tools?

19:13 <kettenis> the recovery environment doesn't have python?

19:13 <marcan> nope

19:13 <marcan> it has perl but just... no.

19:13 <kettenis> heh

19:15 <kettenis> regarding the dcp and agx code, it would be nice if that could would end up being evailable under a non-GPL license (dual licensed or using the same license as the i915/radeon/amdgpu code) such that we can use it in *BSD

19:16 <marcan> we do not load those blobs from the OS

19:16 <marcan> they are loaded from the bootloader

19:16 <marcan> oh you mean the drivers?

19:16 <marcan> everything will be MIT

19:17 <marcan> (dual MIT/GPL)

19:17 <marcan> I made the decision at the start to MIT everything for this and other reasons :-)

19:17 <roxfan2> i think xcode has python3, maybe you can make a minimal env from that one somehow

19:18 <marcan> AIUI this is already the case for the core drm/kms code and the big drivers

19:18 <kettenis> yup

19:19 <kettenis> just making sure alyssa is on board with that as well ;)

19:39 <brentr123[m]> <VinDuv_ "MacPorts can create install pack"> Could just brew install python3 and copy the directory with the files in it and zip it up

19:42 <jix> never used it but it seems there is a py2app thing that generates stand alone app bundles from python scripts and supports arm since the latest release https://py2app.readthedocs.io/en/latest/changelog.html#py2app-0-24

19:45 <marcan> brentr123[m]: I can't figure out how to download homebrew packages, lol

19:45 <marcan> seems ghcr.io needs authentication?

19:45 <marcan> all the URLs in https://formulae.brew.sh/api/bottle/python@3.9.json

19:45 <brentr123[m]> <marcan "brentr123: I can't figure out ho"> Allow me

19:45 <marcan> I assume it wants some token, presumably there is some API flow to get one

19:46 <brentr123[m]> <marcan "I assume it wants some token, pr"> Here

19:46 <brentr123[m]> Run this in terminal

19:46 <brentr123[m]> /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

19:46 <brentr123[m]> Then brew install python3

19:46 <marcan> ... yes I know how to install homebrew

19:46 <marcan> the point being I want to be able to download the package directly so I don't have to

19:46 <marcan> :p

19:46 <marcan> ideally if the installer is python we shouldn't even need to build this on a mac

19:47 <marcan> anyway, I'm off to sleep

20:09 <fedx[m]> I have a 16" MacBook Pro, does Asahi have the drivers I need to install Linux, and is it even possible to install Linux?

20:09 <Serentty[m]> That's Intel.

20:09 <Serentty[m]> Asahi is about the ARM ones.

20:10 <Serentty[m]> You can install Linux on what you have, but it will be very different. If you just do some googling it shouldn't be that hard to find out what you need. Drivers might be slightly painful.

20:11 <fedx[m]> The issue is it has a T2 chip which controls audio, keyboard, and most importantly storage. It is similar to an M1, and M1 Macs did away with a T2 because they have the functionality built in.

20:11 <fedx[m]> It seemed reasonable to think Asahi would work on a T2.

20:11 <Serentty[m]> Yeah, I've heard that that can cause driver pain.

20:12 <Serentty[m]> <fedx[m] "It seemed reasonable to think As"> Unfortunately, everything is really different. The M1 Macs are much more like iOS devices.

20:12 <fedx[m]> Huh, so this is more like jailbreaking or Project Sandcastle and a T2 is just drivers?

20:13 <Serentty[m]> There's no jailbreaking necessary.

20:13 <Serentty[m]> But porting and writing drivers, yes.

20:17 <pipcet[m]> marcan: well, yes, that's why I said A352 rather than applyProperty. I have no idea whether it even is applyProperty here, because of the firmware version dependency.

20:18 <fedx[m]> Ok, any good place to get help with T2 drivers?

20:19 <Bastian[m]> https://t2linux.org/ maybe

21:10 <fedx[m]> OK, Thanks!

23:52 <amw> marcan: Looked at the correllium code and keyboard looks straight forward, SPI + GPIO hardware + patches to apple keyboard driver

23:53 <amw> Can I just start writing fresh code based on reading that and submit a PR or is that too risky?

23:53 <amw> Should this be on #asahi-re? I'm just reading publically available C code on github...