marcan 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
raster has quit [Quit: Gettin' stinky!]
Caloludr has quit [Read error: Connection reset by peer]
odmir has quit [Remote host closed the connection]
<marcan>
also, I wonder how well I could run gentoo on an M1 machine. I have a buildbox, but it's x86 of course
izzyisles[m] has joined #asahi
Augur[m] has joined #asahi
kharit[m] has joined #asahi
<marcan>
I suspect the best way to do it would be to run an arm64 userspace chroot with qemu-user for building, but then use distcc to shell out the actual compilation to a crosscompiler built for x86
<marcan>
(either that or I make a cluster of M1 Minis as an arm64 buildbox9
<marcan>
)
<kettenis>
imac has the same 8-core m1 asthe other machines
radex has joined #asahi
emily has joined #asahi
<kettenis>
so not all that interesting from a developer perspective
<pipcet[m]>
I'm sure they've renumbered the gP pins ;-)
bfredl has joined #asahi
<marcan>
I mean this is a 4-core intel imac...
konradybcio has joined #asahi
<marcan>
hence the threadripper buildbox :@p
<marcan>
:p
<bkero>
marcan: just specify a binhost with gentoo
<dottedmag>
kettenis: So iMac looks like a Mac mini glued to a display, hardware-wise?
<marcan>
bkero: yes, hence I need to mark an arm64 binhost, which is what I was talking about
<marcan>
*make
<marcan>
dottedmag: pretty much
taziden has quit [Ping timeout: 245 seconds]
<marcan>
bkero: if I want to keep using the TR, I'd need to emulate arm64; hence the story with distccing the compiles to the *same* machine, but outside the emulation
<bkero>
marcan: right, although something like crossdev removes the need to use any sort of chroot. It can be handled on the box directly without the slowness of qemu
<bkero>
which would serve the same function as distcc there
<delroth>
this is such a solved problem with nix :)
* delroth
hides
<bkero>
Right, that is another method. You can also use sysroot, which just prefixes instead
<marcan>
I highly doubt sysroot will work for my ~2700-package workstation buildhost
<marcan>
there is no way in hell a true crosscompiling setup won't break on tons of packages
<marcan>
nobody tests this stuff
<marcan>
hence the idea of using qemu-user, but distccing out the builds to a crossdev compiler outside the qemu-user part
<marcan>
it's like that time I had gentoo on a wimpy cortex-a8 board, distccing out to my main machine, except it would be the same machine
<bkero>
Yep, that is a way you can do it. It's slower and the emulation of the compilation/make/linking is unnecessary.
<bkero>
But that probably won't add up over 2700 packages
<delroth>
what I've been doing before having some proper ARMv8 board to run builds on at home is just get an EC2 m6g.2xlarge spot instance
<marcan>
I guess I could just use The Cloud, yeah
<marcan>
I do weekly builds, probably wouldn't be that expensive
<delroth>
turns out you can even get a static IPv6 for free on EC2 (it's not well documented :) ), so I have graviton.delroth.net pointing there and used as a prio 2 nix builder
<delroth>
when it's up it gets used
<marcan>
hå
<marcan>
then again, a mac mini cluster would be cute too
taziden has joined #asahi
<marcan>
anyway, off to sleep
<delroth>
if you want some build capacity temporarily uh
<delroth>
I can possibly give you access to my lx2k board
<delroth>
but really The Cloud is a great option for this too.
<marcan>
unlikely to be worth it with the latency
<marcan>
16-core A72?
<marcan>
also is it actually faster than an M1?
<delroth>
probably not
<delroth>
but builds shard pretty well in general
<delroth>
outside of the critical path
<delroth>
(except for the whole latency problem :-) )
<marcan>
exactly :p
<marcan>
either way I've been meaning to build a Ceph cluster at home out of cheap ARM boards... but if I get like 4 Mac Minis I could dual purpose them as OSDs and build hosts :p
<jannau>
no, mac mini is way faster than 16 core lx2k
<marcan>
nice built in fast as heck SSD for metadata, plug in some USB or TB HDDs for data
<delroth>
A72 is a shitty core yeah
<delroth>
mac mini might be the best option for perf/$ these days in terms of armv8 at home
<delroth>
which is ridiculous given it's apple
taziden has quit [Ping timeout: 245 seconds]
<bkero>
wtb some cortex x1 sbcs
<jannau>
it's a 5+ year old core
<delroth>
(the reason I have the lx2k is more the 4x10Gbps SFP+ than the 16 core A72 :) )
<choozy>
Do any of you know if a part of the Correllium Linux changes are also upstreamed and how and if that interferes or interacts with Asahi's upstreaming efforts?
<j`ey>
choozy: none are upstreamed
<sven>
there was one upstreaming attempt by a third-party afaik
<sven>
but since then there's been no interaction from them on the mailing lists
<choozy>
Ah, I thought they promised to upstream it at some point...
<sven>
speaking of which... i should get back to that iommu patch
<sven>
choozy: i don't think that makes much sense from a business perspective from them. their core knowledge is virtualization and not maintaining linux drivers ;)
<choozy>
Ah okay
<sven>
their proof of concept was good work that showed off their skills and probably even helped them validate their hardware models.
<sven>
but well.. if i was them i'd rather spend my time improving their hypervisor especially since there are enough other people interested in doing that upstreaming work
<pipcet[m]>
I imagine they had a rogue employee working on it and don't know what to do with it yet...
<sven>
hah
<j`ey>
well their CEO was promoting it quite heavily pipcet[m] !
<sven>
i mean that part makes sense. it was good (and deserved) PR for them
<sven>
it might've just been a hobby or a 20% project :)
<pipcet[m]>
not really, I expect it's the community reaction that made them reconsider putting more resources into it
<pipcet[m]>
but, as I said elsewhere, they have email addresses and they do sometimes respond to emails
<klaus>
more M1 macs coming .. it will be good to have proper linux on those too.. an imac and an ipad pro..
<opticron>
yeah, the ipad pro at this point is nearly just a mac tablet which is neat
<pipcet[m]>
sven: do you have the DWC3 working as a USB gadget in Linux or just in m1n1? I'm having a bit of a hard time doing the former
<opticron>
though I wonder if the ipad pro is locked down
<klaus>
especialy when we'll be able to have a good OS on them :)
<sven>
pipcet[m]: linux
<sven>
it was working in linux before i wrote the code for m1n1 actually ;)
<pipcet[m]>
anything special you needed to do to get the UDC to show up?
<sven>
so the easy way to get it to work is to setup the iommu to bypass mode from m1n1, add dma-ranges; to the device tree and patch the dwc3 driver to use 64bit dma addresses
<sven>
for some reason their binding didn't seem to respect dma-ranges and was still stuck with 32bit addresses which won't work
<sven>
(or maybe i messed up)
<pipcet[m]>
is that code available somewhere? It'd be cool to get that to work and it doesn't sound entirely trivial :-)
<sven>
i don't think i pushed it anywhere since it's more of a hack
<delroth>
sven: "upstreaming attempt" might be overstating it a bit
<delroth>
they dumped code on the lkml
ephe_meral1 has quit [Ping timeout: 265 seconds]
odmir has quit [Remote host closed the connection]
odmir has joined #asahi
odmir has quit [Ping timeout: 240 seconds]
<zorun>
hi, I've been following the project for some time, it's really interesting :)
<zorun>
I'm an admin of the compile farm [https://cfarm.tetaneutral.net/], we have a M1 mac mini but it runs MacOS (obviously)
<zorun>
I understand Linux support is not yet ready (e.g. NVMe) but I'm looking forward to the day we will be able to host a M1 running Linux
<zorun>
we have other ARM hosts if it can be of any help for building stuff (the new Jetson AGX Xavier is nice)
<pipcet[m]>
may I ask what the problem is with NVMe? It appears to work quite nicely here.
<bkero>
pipcet[m]: Apple NVMe
<zorun>
yes, support for NVMe on the M1
<opticron>
I think the quirk was that it's a platform device on the M1 instead of being exposed over PCIe
<opticron>
but overall still the same chip and no real expected issues using it
<delroth>
probably still needs DART support to be upstreamed first?
<sven>
nvme isn't behind a DART
<sven>
it's behind what apple calls SART
<sven>
which is.. another iommu i guess
odmir has joined #asahi
VinDuv has quit [Quit: Leaving.]
odmir has quit [Remote host closed the connection]
odmir has joined #asahi
kubes has joined #asahi
kubes has quit [Quit: Leaving]
riker77 has quit [Quit: Quitting IRC - gone for good...]