ChanServ changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
<pipcet[m]>
yes, I think that's the layout of those weird "function" nodes: the first four bytes are the phandle, then the fourcc code, then any arguments.
<marcan>
alyssa: (finally) pushed the DCP stuff to the m1n1/main
<j_ey>
and m1racles perf improvements!
<j_ey>
:P
<pipcet[m]>
j_ey: is gitlab.arm.com down?
<j_ey>
pipcet[m]: yes
<j_ey>
and I suppose it might be till monday now..
<pipcet[m]>
oh, okay. I can look at your keyboard stuff then, I suppose :-)
<j_ey>
pipcet[m]: "can't" I assume you mean. It's just corelliums with a few tweaks to the APIs used, nothing major :-)
<pipcet[m]>
I meant I can look at it when the server's back up
<j_ey>
english is ambiguous!
coin3x[m] has joined #asahi
phire has joined #asahi
<sven>
huh, i just started reading the nvme spec and it seems surprisingly sane so far
<sven>
like, it's actually possible to understand how this works just from the specification
<j_ey>
a bit of light saturday morning reading!
riker77 has quit [Quit: Quitting IRC - gone for good...]
riker77 has joined #asahi
<pipcet[m]>
hmm, what's a good way of crashing the ANS coprocessor so it writes something other than 0xefefefef to the crashlog?
<j_ey>
oh, there's already a GPIO tracer, I didn't know that
<chadmed>
The second sentence after the May 27 tweet should be split into two sentences for better readability. "Effectively, the Python host can 'puppeteer' the M1 and its guest OS remotely. The hypervisor itself is even partially written in Python!"
<tophevich[m]>
I'm not a native speaker, and my duckduckgo foo level didn't help me confirming it, but in the first paragraph you have the "so strap on for a biger update this time". I feel like the phrase is "so strap in" instead of "so strap on"
<chadmed>
youre right a strap on is... well thats something else entirely :P
<tophevich[m]>
;)
<j_ey>
"to the main CPU at any time, even during another options" i suppose that should be 'during another operation'?
<chadmed>
i must say that i am always extremely impressed and delighted when i see very technically proficient people prove themselves as competent communicators. its a very rare skill to be both and you should be proud of your writing marcan
<chadmed>
my real life job is medicine and the number of medical professionals and researchers who simply could not write a clear english passage to save their lives is quite shocking
opticron has quit [Ping timeout: 480 seconds]
<tophevich[m]>
"This has also gotten members of the kernel community interested in our project; having a good relationionship" the transition there feels akward to me, I felt I missed a step, maybe "This has also gotten members of the kernel community interested in our project, and as mentioned previously having a good relationionship"
<chadmed>
i would replace the colon with a fullstop and start a new sentence, "This is important, as having a good relationship..."
<tophevich[m]>
^
opticron has joined #asahi
<tophevich[m]>
"Since the hypervisor is built on m1n1, it works together with Python code running on a separate host machine. Effectively, the Python host can “puppeteer” the M1 and its guest OS remotely, and the hypervisor itself is partially written in Python! This allows us to have a very fast test cycle, even updating parts of the hypervisor itself live during guest execution, without a reboot."
<tophevich[m]>
I would move the partially written in python part to the second sentenace. -> "Since the hypervisor is built on m1n1, it works together with Python code running on a separate host machine. Effectively, the Python host can “puppeteer” the M1 and its guest OS remotely. To allow us a very fast test cycle, the hypervisor itself is partially written in Python, which allowes even updating parts of the hypervisor itself live during guest
<tophevich[m]>
execution, without a reboot."
<tophevich[m]>
(hm ... looks like I should proof read my proposals)
<chadmed>
IRC drafting... i will never criticise graphical word processing applications again ;)
<tophevich[m]>
"Apple decided to throw a twist into it" feels like two phrases merged, i think a simple "Apple decided to give it a twist" sounds more "native". You can throw a wrench into "the gears" but a you can't trhow a twist, the twist itself is the action.
<tophevich[m]>
At some points you go into explaining some of the acronyms, but for others you do not. It always depends on what you have in mind for your target audience, but you could do it more often at the first mention or just add a glossary?
<chadmed>
i think the problem is that we do not know for sure what some of the acronyms actually mean. DCP, for example, may simply mean Display Control Processor but we simply dont know
<tophevich[m]>
One example is "Sven has been dutifully working on the Linux driver for DART, the M1’s IOMMU (I/O Memory Management Unit)"
<AkihikoOdaki[m]>
"On top of this, the DCP implements multiple endpoints, one of which serves as the “main” inteface." *interface
<sven>
dart = device address resolution table fwiw, not sure if anyone actually cares about that though
<tophevich[m]>
sven: I know that but if you don't know IOMMU, do you know DART?
<AkihikoOdaki[m]>
"the DCP can send asynchronous messages to the main CPU at any time, even during another options." options -> operations?
<tophevich[m]>
"directory structuers and files" -> structures
<sven>
tophevich[m]: if you don't know IOMMU will "I/O Memory Management Unit" be helpful? i'd probably just put a link to a wikipedia page or something there
<tophevich[m]>
:j_ey ok, I guess it would be a good idea to link to it as part of the article. And it matches realy nicely as IOMMU is not in the glossary but is "expanded" in the article :D
<tophevich[m]>
only the glossary mentions the IOMMU without expanding on it :D
<sorear>
But what most people think of as a “GPU” is actually two completely distinct pieces of hardware: the GPU proper, which is in charge of rendering images, and the display controller, which is in charge of sending those rendered images to the display. <-- this is a little clumsy both for the "most people think" bit and the vagueness of "rendered images"
<chadmed>
substituting "frames" for "images" may help clear up this ambiguity
<sorear>
thinking something like: But what most people think of as a “GPU” is actually two completely distinct pieces of hardware: the GPU proper, which is in charge of rendering images to pixels in memory, and the display controller, which is in charge of sending those pixels from memory to the display.
<sorear>
there might be a small lie in the first bit because an informal "GPU" also includes video codecs, which I don't think are part of DCP or AGX, but I'm not sure what the best way around that is
<chadmed>
yeah but i dont think it particularly matters for this text. its a conversational piece describing what the developers have been up to over the last couple of months, not a set of specifications or technical documentation
<chadmed>
the important takeaway from that passage is that the DCP is a distinct coprocessor with its own firmware
<chadmed>
that comes across just fine
<sorear>
"However, we do have access to the raw display controller registers too" not an editing comment but I'm wondering how we found this out, given that we can't trace DCP
<tophevich[m]>
(updated the wiki as a direct result of the article glossary discussion, hope that's ok)
<sven>
that's perfect! it's what wikis are for :)
<sorear>
EOF
<tophevich[m]>
/!\ /!\ /!\ the deep-links in the article to github files could become a problem in the not too distant future. I think it would be a good idea to use a commit specific link, otherwise they could become obsolete in "next weeks" refactoring and you'd get a 404.
<kettenis_>
hi
<kettenis_>
done some hiking hence my absence
<sorear>
overall very nice piece, my desire for a clear statement of the current status of usb/pcie/spi/nvme etc remains unsated but that's not on any of you
<chadmed>
i think the problem there is that its all at a "well it kinda works but not really" level so theres no point reporting that we have progress on it, then have a bunch of people think that means they can just use brcmfmac and have a working desktop
<chadmed>
its the same principle as not cluttering the install instructions with technical documentation, someone or many someones _will_ misinterpret what is written and then come complaining that we misrepresented what you can do. "you said that usb works so how come i cant use my HOTAS system as an input device >:("
<sorear>
i think the same argument could be used to suppress all of the discussion of DCP progress
<chadmed>
eh not really since its a very obvious state of affairs. we can manually package up a frame and push it to the screen and really not much else. with the other controller drivers, we have had a couple of instances of silent data corruption, some usb hubs not working properly, usb-pd not working, the nvme controller preventing the system from shutting down cleanly etc
<marcan>
sorear: initially corellium, since they patch up the framebuffer format directly in their preloader
<marcan>
but recently I scanned the entire MMIO range around that and DCP and found a lot of fun registers
<marcan>
things like histograms of pixel values
<marcan>
tophevich[m]: I think I already did the relevant refactor this time around, but I can always update the article if they break again
<marcan>
I'm a bit reluctant to pin the revisions right now since that code will probably change a lot and I don't want to send people to outdated versions
<marcan>
sorear: that part is what I'm going to focus next, so... :)
<sorear>
focus for code or for words?
<marcan>
for code
<tophevich[m]>
marcan: hm, ok but shouldn't be the explanation and the source be in sync. I wouldn't expect ppl using those to gather them only from the article but to check out the repo.
<marcan>
could be, yeah
<marcan>
might decide to pin them a bit later
<marcan>
chadmed, tophevich[m], j_ey, sorear: thanks for the review! Just pushed a bunch of changes
<j_ey>
ship it!
landscape15[m] has joined #asahi
duckworld has joined #asahi
<sven>
sorear: pcie (and with that ethernet and usb a) requires gpio/pinctrl, ~100 lines of magic register pokes and some thinking about how to handle the rid2sid iommu mapping. that's maybe a day or so of work now that DART is done.
<sven>
usb-c requires the usb phy driver (ugh...) and some way to get an interrupt when a new device is connected (usb-pd is a good guess, but there might also be a SMC event). otherwise it already works with an upstream kernel in bypass mode, but now also with an iommu since DART is done for now
<sven>
nvme requires me to take nvme/pci.c, strip off all the PCI-specific stuff and create apple-ans.c. it also needs a simple hv tracer to figure out some details (how does the nvmmu actually work + how to shutdown the controller) and then ofc asc/rtkit
<sven>
and broadcom wifi needs some patches to the upstream driver. might be possible to take corellium's patches and just submit them as-is
duckworld is now known as jmyers
<sven>
i think the most important stuff right now are clocks, gpio, pinctrl and then spi and i2c. they're all relatively simple but are required for a lot of the fun stuff later on
jmyers is now known as duckworld
duckworld has quit [Remote host closed the connection]
duckworld has joined #asahi
<sorear>
thank
<sven>
and ofc some asahi-next branch or something like that would be really nice ;)
<j_ey>
sven: I hope my changes on top of corelliums patches come in handy, but if not its a good learning experience :D
<sven>
getting gpio/pinctrl upstream would be very helpful :)
duckworld has left #asahi [#asahi]
<pipcet[m]>
sven: what are you going to work on next?
<j_ey>
kettenis_: so do we think there's only 2 functions in pinctrl? gpio/periph, and periph is basically fixed to something depending on what its connected to?
yuyichao has joined #asahi
<alyssa>
marcan: w00t w00t!
<kettenis_>
i think there might be a total of 2 bits for the function
<j_ey>
oh
<kettenis_>
the dt binding has enough bits to encode more functions
<kettenis_>
only seen one bit being used so far
<kettenis_>
so that is probably good enough for now
robinp has joined #asahi
jelly has joined #asahi
<robinp>
marcan: s/"Apple silicon"/"Apple Silicon" (capital S in installation section)
yuyichao has quit [Ping timeout: 480 seconds]
<marcan>
robinp: thanks, fixed :)
kwilczynski has joined #asahi
dung[m] is now known as parabola[m]
bps2 has joined #asahi
zopieux has quit [Ping timeout: 480 seconds]
zopieux has joined #asahi
<sven>
pipcet[m]: nvme i guess
<sven>
well, that and the patch series to support 16k iommus on 4k kernels
jeffmiw has joined #asahi
<mini_>
just finished reading the progress update, thanks for posting it :) great progress being made!
mini_ is now known as mini
awal has joined #asahi
cptcobalt has quit [Read error: Connection reset by peer]
cptcobalt has joined #asahi
everslick has joined #asahi
awal has quit [Quit: bye]
<alyssa>
got PCIe/USB-A/Ethernet working on linux booted straight from m1n1
<alyssa>
(without roundtripping through u-boot which breaks smp for linux..)
<alyssa>
maz: 's PCIe driver
<alyssa>
with hw initialized added ported from
<alyssa>
kettenis_: 's uboot driver and dt
<alyssa>
(which in turn is based on the corellium driver, so that was a funny way to round trip back to linux)
roxfan2 has joined #asahi
<alyssa>
and of course couldn't do it without
<alyssa>
sven: helping me debug all my dumb mistakes for days texting back and forth ❤️
<alyssa>
oh and
<alyssa>
j_ey: 's pinctrl driver which itself is a cleaned up version of corellium's pinctrl
<alyssa>
and uhhh corellium's SMC driver and
<alyssa>
sven: 's IOP (mailbox) driver
<alyssa>
and last and definitely least, my pile of duct tape
<j_ey>
^_^
<tophevich[m]>
gz to all :)
<pipcet[m]>
alyssa: that is awesome! If you put it up somewhere, I can see whether wifi works :-)
<alyssa>
pipcet[m]: ack
<alyssa>
current patch stack is an absolute mess, will need a few minutes to rebase
<alyssa>
but first, food. obviously.
<alyssa>
😉
<alyssa>
the other big hack here is sven's "enable all clocks" hack in m1n1 and the "clk_keep_unused" kernel arg since there's some isssues with clocks, but I figured I'd deal with the reg pokes first.
<alyssa>
goal for the weekend is to get this all cleaned up, get an RFC on the LKML, and get a tree that y'all can actually try which has PCIe/USB/Ethernet/SMP working properly
roxfan has quit [Ping timeout: 480 seconds]
<alyssa>
(for the last 2 days of last week, I was using the m1 for real work but pushing everything over a usb-c hub. which is... not great ;-p)
<alyssa>
so plan is to get this clenaed up now and then i'll be daily driving the branch
<alyssa>
said branch won't have NVMe, i'm using an external drive for now since I like my data/
<alyssa>
(There are two indepnendent NVMe drivers right now -- the asahi/nvme branch and the corellium nvme driver -- and it's my understanding both are giant hacks. TO be fair to everyone involved, it's also my understand the M1 ANS stuff is wild.)
<sven>
awesome!
<sven>
asahi/nvme is actually close to how the final driver will look. just with cp pci.c apple-ans.c and lots of removed code
<pipcet[m]>
sven: I got it to work here, found some (very) minor things but it seems to be working (and yes, I realize it'll eat all my data)
<marcan>
sven: didn't arnd already have platform bindings for nvme?
Andalu30 has joined #asahi
<arnd>
marcan: my original version skipped that part, I think sven added the obvious properties
<marcan>
ah
<sven>
and one of the nvme maintainers found my WIP branch and essentially said that we should copy pci.c, remove all stuff that isn't supported/used by apple's chip and just keep a duplicate copy of the shared code
<sven>
(asahi/nvme essentially is arnd's platform work with like 3 lines changes + patches to the nvme core to support apple's new queue format and their nvme-iommu)
<sven>
*changed
<kettenis_>
with asahi/nvme you mean the nvme/dev branch?
<kettenis_>
not sure if the generic-nvmexpress compatible makes sense
<alyssa>
i still need to fix clocks yes.
<sven>
kettenis_: it doesn't, that branch is still very much WIP
<sven>
still not happy about the mbox with the fake endpoint either
<alyssa>
had my KMS stub in there, removed
<alyssa>
aside - rebasing linux is noticeably slower than mesa..
<kettenis_>
the ans copro does advertise that endpoint though isn't it?
<sven>
yes, and that endpoint is called "smc" and the other one "ans"
<pipcet[m]>
yes, it does.
<sven>
i *think* it can somehow talk to SMC with that
<pipcet[m]>
but do we need to start it to get things working?
<kettenis_>
maybe we should just have m1n1 start it?
<pipcet[m]>
why?
<kettenis_>
why not?
<sven>
this all kinda circles back to the question how to handle mailboxes/rtkit in general
<pipcet[m]>
kettenis: well, without getting into the "accept hardware in any reasonable state it is in" argument, I really don't see the benefit. DTs are perfectly happy expressing the relationship, and it's legitimate to open a mailbox channel you might never use..
<kettenis_>
the "fake" endpoint works fine for u-boot
<pipcet[m]>
and I think endpoints are stopped by the reset sequence that we need to perform on the ANS so it won't write to random memory...
<sven>
we can do all the rtkit stuff inside mailbox (see nvme/dev) but i kinda expect that will get shot down rather quickly on LKML
<kettenis_>
but if folks don't want to rely on u-boot then you run into the qiestion what state linux expects the copro to be in
<pipcet[m]>
"resettable" or "not started"
<kettenis_>
u-boot will reserve the memory it gives to the copro for logging so there is no overwrite risk
<kettenis_>
but m1n1 could do the same
<sven>
we need to handle the exact same thing for other processors anyway inside linux (dcp, smc and who knows what else)
<kettenis_>
true
<pipcet[m]>
well, SMC and ANS are special because the boot loader might reasonably use them.
<sven>
then the bootloader better should just shut them down again
<pipcet[m]>
sure. how?
<sven>
same as e.g. iboot does
<sven>
uh, i've mentioned the sequence and i think there's even code in the nvme/dev branch for that
<sven>
you can also just crash either processor early on while mac os boots and it will happily print the mailbox log with the messages iboot sent to shut them down fwiw
<pipcet[m]>
i played with that very briefly and macos just rebooted when i crashed the smc
<kettenis_>
sven, fwiw handling the SART in the mailbox driver instead of the nvme driver makes sense to me
<alyssa>
sven: is there a magic sequence to reboot DCP if it crashes?
<sven>
kettenis_: yeah, i think whatever end up handling the rtkit endpoints should also handle SART
<sven>
alyssa: so "shutdown" really means "put into hibernation/low-power mode". there's a possibility to restart them, but that hasn't worked for ANS or SMC and i doubt it works for DCP
<sven>
some combination of (first write32(asc_base + 0x10004, 0x11) then write32(asc_base + 0x10004 + 0x20, 0x1)), (clear that bit in asc_base+0x44 that's used to start them) and (set bit 31 in the clock gate register, delay for a bit, clear that bit again)
ZLSA has quit [Read error: Connection reset by peer]
mindfreeze has quit [Remote host closed the connection]
<alyssa>
ah.
WhyNotHugo has quit [Ping timeout: 480 seconds]
austriancoder has quit [Ping timeout: 480 seconds]
ovf has quit [Ping timeout: 480 seconds]
rann has quit [Ping timeout: 480 seconds]
<sven>
you don't sounds convinced ;)
enomem has quit [Remote host closed the connection]
<sven>
*sound
kwilczynski has quit [Ping timeout: 480 seconds]
arnd has quit [Ping timeout: 480 seconds]
enomem has joined #asahi
esden has quit [Ping timeout: 480 seconds]
austriancoder has joined #asahi
kwilczynski has joined #asahi
arnd has joined #asahi
awal has joined #asahi
DarkShadow44 has joined #asahi
WhyNotHugo has joined #asahi
ovf has joined #asahi
mindfreeze has joined #asahi
ZLSA has joined #asahi
esden has joined #asahi
roxfan2 has quit [Remote host closed the connection]
rann has joined #asahi
roxfan has joined #asahi
Andalu30 has quit [Ping timeout: 480 seconds]
<alyssa>
"that hasn't worked for ANS or SMC and i doubt it works for DCP"
<alyssa>
Very convincing ;-)
<alyssa>
pipcet[m]: Does shutdown (not reboot) work on pearl?
<roxfan>
sounds like a challenge
<pipcet[m]>
you mean poweroff? yes.
<alyssa>
corellium's patch doesn't work for me (it reboots)
<pipcet[m]>
you've got the nvmem driver?
<alyssa>
No. That's probably why :-p
<pipcet[m]>
printk("hold the power button for ten seconds\n");
<alyssa>
pipcet[m]: hahaha
<alyssa>
sven: the corellium reboot driver looks pretty self-contained, might be a good candidate to send off to the LKML almost as-is
<pipcet[m]>
alyssa: can't we use the wdt driver? it handles reboots fine :-)
<alyssa>
pipcet[m]: didn't work when I tried it and assumed I misunderstood what it was for
<alyssa>
do we know how macOS reboots?
<pipcet[m]>
oh no :-(
<pipcet[m]>
well, the corellium reboot driver does the same thing as the WDT driver so I'm stumped.
<alyssa>
Oh
<alyssa>
uhhh
izica[m] has joined #asahi
izica[m] is now known as izica
<alyssa>
Does anyone have strong preferences about github vs gitlab for kernel repo?
<ar>
alyssa: I don't participate in kernel development, especially around here, but github's always been terribad for code reviews
<ar>
alyssa: and for tracking issues too
yuyichao has joined #asahi
<kettenis_>
alyssa: using the WDT to reboot works fine in u-boot and openbsd
<kettenis_>
(but doesn't do powerdown of course)
<alyssa>
kettenis_: ack 👍
Andalu30 has joined #asahi
<jn>
alyssa: regarding ar's comments, which features are you going to use? just git hosting and code browsing, or also review, issues, etc.?
Andalu30 has quit [Ping timeout: 480 seconds]
<alyssa>
jn: review, mainly. and maybe wiki
<alyssa>
...is pushing a linux repo to github supposed to work ?
<alyssa>
send-pack: unexpected disconnect while reading sideband packet
<j_ey>
alyssa: maybe fork it. so you dont have to push all of the history?
<alyssa>
j_ey: will try that. i'm a young old hat.
<j_ey>
and if you dont want to fork, just push the history in chunks
<TellowKrinkle[m]>
GitHub also has an issue where forks and non-default branches aren't searchable, which annoys me
<TellowKrinkle[m]>
Also GH search is surprisingly terrible at actually finding things, can't comment on GitLab here though
<alyssa>
this also annoys me.
<j_ey>
TellowKrinkle[m]: yeh thats annoying
<JTL>
meh. I just git clone and grep when I what to search for something other than a known string
<j_ey>
alyssa: I ran something like: for tag in 2.6 3.0 3.3 3.6 3.9 4.1 ; do push $tag ; done
<alyssa>
I tried doing a github fork of torvalds/linux and am pushing now
<alyssa>
although I rebased on linux-next, not torvalds' tree, so the diff will be ugly. oh well.
<jn>
TellowKrinkle[m]: oh yes. it searches for words at best. searching for exact syntax (an unsurprising task for a *code search engine*) absolutely doesn't work
<TellowKrinkle[m]>
JTL: When I say terrible, even searching for known strings doesn't work half the time
<j_ey>
alyssa: you just need it to get the 1 million commits of history!
<alyssa>
TellowKrinkle[m]: On the other hand, searching all of GitHub is an excellent reverse-engineering technique 😋