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-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
___nick___ has joined #asahi
boardwalk has joined #asahi
malvo has quit [Ping timeout: 480 seconds]
malvo has joined #asahi
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
marvin24 has joined #asahi
marvin24_ has quit [Ping timeout: 480 seconds]
quarkyalice__ has joined #asahi
artemist has quit [Ping timeout: 480 seconds]
quarkyalice__ has quit [Ping timeout: 480 seconds]
artemist has joined #asahi
<lemonsus[m]>
Hey, noob here. I was just a little confused on what Asahi is supposed to be or how it would work for a noob like me. So for example when I installed Linux on my x86 laptop, I just used a Pop!_OS ISO and was able to install it via USB. What would be different with Asahi? and what sort of caveats might there be with installing and using Linux on an M1 as opposed to x86?
<chadmed>
the process for installing would be slightly different but there is an install helper in the works to make this as painless as possible. as for the second question, you may find that some of the software you use on a day to day basis has no arm64 binaries, so youll need to find alternatives. arm support is mature in most distros though so if you use your distro's repos you shouldnt find too many examples of this
<chadmed>
the big show stopper is gaming of course, though i plan on trying some funky stuff with qemu-user once we have vulkan support just to see how viable it is. some dude on youtube got gta v's windows build working via rosetta 2 in a vm at 60 fps which is extremely impressive, but i fear qemu-user is a whole lot slower than rosetta
<phire>
you might be interested in FEX. It's still a work in progress but it's aiming to be a much faster qemu-user
<phire>
there is also box86/box64, but I don't know much about them
<chadmed>
yeah marcan recommended fex last time i mentioned trying to get csgo up and running
<marcan>
yeah, FEX is probably the future
<marcan>
assuming it works well enough, that's something that would be preinstalled/configured in our arch images once we have them
<marcan>
so... sounds like I have a Mac Mini teardown + scope probing stream to do today...
<marcan>
... need to get a corner of my room clean first though
<i509vcb[m]>
At least some stuff like the JVM has aarch64 support, I think it's a 4x performance reduction to run that through rosetta
<i509vcb[m]>
Likely because you have 2 layers of JIT compliation
<chadmed>
virtually everything that people use every day will have aarch64 support if youre grabbing it from a big distro
<i509vcb[m]>
Until JDK 17 (GA 3 days ago) you actually had to use an early access build on macos to not use rosetta
<chadmed>
yeah but thats a macos ABI problem not an aarch64 problem
<marcan>
linux has much better arm64 support out of the box than macos, and likely will for at least a couple more years
<marcan>
because it's been supported for a long time now
<marcan>
conversely, Apple did a really good job with Rosetta to work around that
<chadmed>
rosetta 2 really is quite impressive yeah
<i509vcb[m]>
aarch64 on linux has definitely worked well in my experience, although kinda annoying that pi I had was faulty out of the box
<i509vcb[m]>
eh just rambling at this point
<chadmed>
your first mistake was buying a pi tbh
<marcan>
talking about distro support here; hardware is a whole different story
<marcan>
let's just say it's, uh, been a long road to pis getting onboard the upstreaming/proper drivers train
<phire>
if rosetta 2 follows the path of rosetta 1, it won't stick around for long
<chadmed>
feral ghoulish piece of hardware, barely anything works properly without their proprietary blobs, downstream kernel and downstream binaries in their raspberry pi os repos
<phire>
apple will kill it to force vendors to port their applications to native
<marcan>
these days you can use upstream kernels, especially with the pi 4 and such IIRC
<marcan>
but yeah, it's still a patchfest to get everything working properly
<marcan>
that's exactly what I *don't* want to happen with Asahi
<marcan>
which is why we're shaving all the yaks
<marcan>
last night I wrote the 3rd attempt at a clocks driver (now a genpd driver)
<chadmed>
marcan: i spent a good few months doing *nothing* in my spare time but trying to get my pi 4 working with a completely upstream gentoo root, just gave up in the end
<marcan>
I think this has a good chance of being the good one
<marcan>
(branch pmgr/dev on our repo)
<marcan>
so now this unblocks upstreaming all the other drivers, and also thanks to the way this all works (much more nicely than the old clock framework), isn't really a hard dependency in any direction
<marcan>
I'm very happy with how it worked out
<marcan>
today let's see if I can debug that weirdo USB thing with an oscilloscope; then after that cpufreq which will be simple since it's using the same framework, just with frequency switching enabled
<marcan>
and I guess at that point, with sven sending off i2c etc, all I really have to do urgently is put together an asahi/devel testing branch or such, finally...
<marcan>
... and then, finally, it's time to tackle the GPU
<marcan>
so hopefully by next week I'll be in GPU mode
<chadmed>
ganbare
maor26 has joined #asahi
aleasto has joined #asahi
<tophevich[m]>
marcan: It's been some time seeing you kernal hacking on stream, might we get to enjoy one some time after the hardware debugging session?
quarkyalice has quit [Remote host closed the connection]
* tophevich[m]
also hasn't seen you streaming kern_e_l hacking in a while :D
<marcan>
tophevich[m]: kernel is what's next, I just keep distracting myself with hardware reverse engineering in preparation of :p
<marcan>
(like right now; I just poked around the PMGR pstate bits some more...)
<tophevich[m]>
marcan: those poking sessions are very welcome, my comment should not invoke the perception that I would rate one over the other, just that if you do kernel hacking, I'd be interessted follow you on those as well :)
<marcan>
j_ey: low because I got distracted with pmgr stuff *again*... finally worked out what the clocks/events/power domains fields are (mostly)
<marcan>
that now explains the massive init sequence that the pmgr driver does, it's scanning through all the tables that dump_pmgr.py prints and poking those registers (which are in a big array, somehow)
<marcan>
not entirely sure what those registers represent, seeing as they are homogeneous for devices/clocks/pds/events
<marcan>
but at least with that there's no more "lists of magic pokes" left that we can't explain
<marcan>
maybe m1n1 should do this init... though we don't really know what it does yet
<marcan>
tophevich[m]: I normally stream whatever I do as long as I'm in the mood; I was actually originally planning to stream last night's thing but I ended up too tired, though I'd sleep, then couldn't sleep, then decided to hack on that driver anyway... not quite up for a stream at that point :p
<marcan>
*thought
<j_ey>
the driver was only like 500 lines in the end
<j_ey>
err 141 lines lol
<j_ey>
usually its ~200 lines for a driver that basically does nothing!
<marcan>
yeah, the work was mostly figuring out how the genpd stuff works!
<marcan>
thankfully it's pretty simple :)
<marcan>
also I think I spent more time adding runtime PM to the serial driver (because sequencing and enable/disable mismatches and...) :p
<j_ey>
probably not if you include all the pmgr RE time :P
<marcan>
sure :p
<marcan>
though so far most of that has been "finding out all the things I don't need to care about"
<tophevich[m]>
marcan: yes, most important is that you hit your groove, if a stream fits into that, it's only sugar on top. I'm not trying to push you to stream, just want to make sure you know it is appreciated.
<marcan>
the PLLs are *locked*, we can't get ourselves into that mess even if we wanted to!
<marcan>
thank you apple security design
<marcan>
means they can't afford to let osx do anything nasty :D
<marcan>
also, seriously, no other SoC vendor does this remotely this well
quarkyalice has joined #asahi
<marcan>
tophevich[m]: I'm happy that people enjoy them :)
quarkyalice__ has joined #asahi
<marcan>
I think to this day the most no-nonsense system I'd seen was the Wii, but that still has some memory init (that we never had to worry about because it was done by the stage 1 bootloader) and some PLL (?) and related nonsense (that we did, since we replaced the stage 2 bootloader)
<marcan>
but the M1 is arguably even better, especially relative to all the stuff it does
<milek7>
I dunno, 'tons of signed proprietary firmware' doesn't sound that good to me
quarkyalice_ has quit [Ping timeout: 480 seconds]
quarkyalice_ has joined #asahi
<marcan>
tons of signed proprietary firmware that works, does its job, is behind IOMMUs so cannot backdoor the main system, and takes a ton of work off of Linux? I have no problem with that
<marcan>
proprietary firmware is only a problem when it becomes a problem
quarkyalice has quit [Ping timeout: 480 seconds]
<marcan>
everything runs proprietary firmware; people don't generally complain about the blob in their mouse because it works and doesn't get in the way
quarkyalice has joined #asahi
quarkyalice__ has quit [Ping timeout: 480 seconds]
quarkyalice_ has quit [Ping timeout: 480 seconds]
frode_0xa has joined #asahi
<phire>
I'm curious if it's possible to overclock the Wii's VI, make it output more than 480p
<phire>
Though the AV encoder chip might be the actual limiitation.
frode_0xa has quit [Quit: leaving]
frode_0xa has joined #asahi
<tophevich[m]>
marcan: You hit the nail on the head with the example. I think this is something where we humans are very much intuitively wrong, as if we see something seperated (in our mind clearly seperated) it is "OK", because it is not part of the system. But in reality that seperation is quite arbitrary. If it is "part" of your system, the firmware seems to be software, if it is not it seems to be part of the hardware ... But as a system is by
<tophevich[m]>
definition created by many distinct parts, this distinction can only be made arbitrary and there our intuition will fall back to what we perceive physically as seperate. Also at which point is firmware, and at which point does it become software. What kind of firmware can be "seen" as "hardware"?
<dottedmag>
any* Linux sits on top of tons of immutable proprietary hardware. why single out firmware? (*except RISC-V on top of a OpenFPGA-chip that you have somehow manufactured manually?)
<dottedmag>
tophevich[m]: Is the distinction trully useful? I don't see practical differences between hardwired circuits, a resident blob in hardware, loadable firmware and a proprietary driver as long as it does not cause problems.
<dottedmag>
The only kinda-useful difference is for pluggable peripherals, where you don't want to be running a proprietary driver on the main CPU, because you'll be limited in the set of machines you might plug this peripheral into.
<tophevich[m]>
marcan: What I'm saying (trying to) is that in most cases it is most likely not useful, but that we humans will do it anyways as we are "programmed "to do so. And as we know that is the case we need to remind ourselves of the fact that we do it intuitivly wrong in most/many cases, as we will do it on physical perception ...
<tophevich[m]>
I mean in general, regarding those topics you realy want to answer (or it boils down to), how much control do I have over my hardware, and how much control has my hardware over me. Be it data privacy, security, usability, availabilty ... That's what you want to have realy answered I think.
<tophevich[m]>
Or how much it can be trusted in to do as expected in those regards
<alyssa>
marcan: "all I really have to do urgently is put together an asahi/devel testing branch or such"
<alyssa>
you won't be able to automate this, and I've already sunk in the cost of dealing with this. go to gpu, do not pass go, do not collect 200 yen
<tophevich[m]>
:D
chadmed has joined #asahi
leah2 has quit [Remote host closed the connection]
leah2 has joined #asahi
awal3 has joined #asahi
frode_0xa has quit [Quit: leaving]
jbowen has joined #asahi
X-Scale has joined #asahi
X-Scale` has quit [Ping timeout: 480 seconds]
malvo has quit [Ping timeout: 480 seconds]
malvo has joined #asahi
malvo has quit [Ping timeout: 480 seconds]
malvo has joined #asahi
<marcan>
alyssa: I'm not trying to automate this any more, I intend to just do some manual merges and call it a day
skipwich has joined #asahi
<alyssa>
right.
skipwich has quit [Remote host closed the connection]
skipwich has joined #asahi
<j_ey>
marcan: lool man, smp in the hv is insane
<j_ey>
that progress bar was like 5mins before I think? now 2s
<marcan>
:D
<marcan>
alyssa: also 200 yen... that's barely enough for a coffee :p
<j_ey>
marcan: it's annoying it seems in gpio/pinctrl there's no interrupt enable/disable. you have to clear the the interrupt type to 0, so to enable it again you have to write the type out again, which means storing the type in the driver
<marcan>
heh, annoying...
<kettenis>
j_ey, does assigning the interrupt to group 0 work?
<j_ey>
kettenis: group 0 is a valid group!
<kettenis>
group 7 then?
<j_ey>
also valid
<kettenis>
one of the 8 groups has no AIC interrupt associated with it
<j_ey>
hmm
<j_ey>
now Im confused :)
<alyssa>
starting "introduction to sw design" homework, someone get the stopwatch
bdju has joined #asahi
<alyssa>
done
<alyssa>
(for the week)
<j_ey>
8:43
<alyssa>
j_ey: thx
<j_ey>
maybe you should do 2 nd major
<alyssa>
<marcan> TIL you're also a goddamn formal mathematician
yuyichao has quit [Ping timeout: 480 seconds]
<kettenis>
heh, I suppose I could consider myself an informal mathematician
Andalu30 has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi
quarkyalice__ has joined #asahi
quarkyalice__ has quit [Remote host closed the connection]
<roxfan>
"pointer arithmetician"
maor has joined #asahi
maor26 has quit [Ping timeout: 480 seconds]
<sven>
i technically have a physics degree. that surely also makes some kind of mathematician!
<j_ey>
oh yeah, you have a physics degree? what's plancks constant?
<sorear>
that's something you've only been able to memorize in the last 2 years
<sven>
j_ey: 1 in natural units :P
<dottedmag>
j_ey: It's a constant someone came up with to give Maltese people a letter for H sound (they have misused their H letter to mean "no sound")
<j_ey>
sven: bah youre too clever
<sven>
must be the physics degree! :-P
<kettenis>
c = 1, h = 1, h_bar = 1
<j_ey>
e = mc^2
<sorear>
kettenis: 2pi = 1?
<kettenis>
yeah, that's where things wnet wrong...
<kettenis>
so now you know why i do this computer stuff
<povik>
yeah, i don't know if /arm-io/gpio has any
<povik>
that didn't stop me from trying
<alyssa>
sounds about right for r/e experiments
<alyssa>
hm this isn't coming up reliably
<povik>
works best after fresh reboot
<alyssa>
also that
<alyssa>
(not discounting sox weirdnesses ofc)
<alyssa>
povik: -r 48000 fixes the distortion 👍
<povik>
great, i put it in the paste
<alyssa>
povik: do we know if this is the 'right' way of driving audio?
<povik>
what's the 'right' way?
<alyssa>
No idea, I'm a graphics person :-p
<povik>
well then we should ask someone
<alyssa>
but like -- for display, you can technically drive the display registers directly. but you're not supposed to, that's the DCP's responsibility
<alyssa>
(as is very clear from a hv trace of macOS)
<povik>
right, well no, i am not missing a coprocessor in the loop
<alyssa>
👍
<alyssa>
anyway, great work 🙂
<alyssa>
headphones next? 😋
<povik>
could be easy now
<povik>
but there's an exam i have to study for first
<povik>
guess i exhausted the procrastination budget
<alyssa>
relatable.
<povik>
thought so
<roxfan>
hm, ios15 is out but not macos 12
<roxfan>
still buggy?
<kettenis>
I think I have the power domain stuff sorted out for u-boot
<kettenis>
still need to sort out the dependencies for the various devices that aren't in marcan's device tree yet
<kettenis>
but the "children of syscon
<kettenis>
" model seems to work fine in u-boot
<roxfan>
children of the syscorn
<j_ey>
it does sound like a band name
jbowen has quit [Quit: leaving]
<alyssa>
povik: also, licensing for that python code? (so we can stick it in m1n1/experiments)
<povik>
alyssa: anyone can do as they please with it
<povik>
i will be happy to prepare a PR under the standard m1n1 license (MIT, i think?)
<alyssa>
please do so :-)
<povik>
okay, will do tomorrow probably
<alyssa>
cool!
maz has quit [Read error: Connection reset by peer]
maz has joined #asahi
aleasto has quit [Quit: Konversation terminated!]
povik has quit [Quit: Page closed]
aleasto has joined #asahi
aleasto has quit []
aleasto has joined #asahi
aleasto has quit [Remote host closed the connection]
aleasto has joined #asahi
aleasto has quit [Quit: Konversation terminated!]
<alyssa>
looking at the ADT, i guess headphones are over i2c2 with the cs42l83 part
<alyssa>
that particular chip doesn't have linux support, but related e.g. cs42l73 is there
mindw0rk[m] has joined #asahi
psykose has quit [Ping timeout: 480 seconds]
<alyssa>
ok uh back to gfx
<alyssa>
marcan: hv is giving me an SError now with the macos stuff