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
skipwich has joined #asahi
<citizen1[m]> <MTecknology> "I assumed so, since I'm currentl..." <- 🤣🤣
<citizen1[m]> but not all ARM apps are equal. Say an ARM Android game , will it just play on ARM M1 ? doesnt it need to be recorded or ported to the other platform?
<linearcannon> well, if that M1 is running android, then yes, it will just ply
quarkyalice has quit [Ping timeout: 480 seconds]
<alyssa> linearcannon: stuff of nightmares
chadmed has joined #asahi
chadmed has quit [Remote host closed the connection]
ZLSA has quit [Read error: Connection reset by peer]
rann has quit [Remote host closed the connection]
arnd has quit [Remote host closed the connection]
ZLSA has joined #asahi
arnd has joined #asahi
rann has joined #asahi
<marcan> MTecknology: that game does not have a Linux ARM build (almost no games do)
<marcan> you'll have to use something like https://github.com/FEX-Emu/FEX but I've never tried it, so I have no idea how well that works
<marcan> I'm interested in contributing to FEX once things get to a good point hardware-wise, since it's important to people to have a good x86 emulator, but strictly speaking it's outside the primary scope of the project (which is hardware compat)
<marcan> android aside that is; in principle you could run android versions of games if you have some kind of android container thing
<marcan> seems that game requires steam to download too; I have no idea how well steam runs on emulators like that, if at all. steam is kind of a mess.
<alyssa> marcan: the annoying interaction with FEX is that it strongly assumes 4K pages
<alyssa> so will need sven's patches at least
<marcan> alyssa: that's unsurprising, since x86 apps kind of do
<marcan> this is why macos supports 4k pages
<marcan> to make that kind of thing work with 16k pages needs some hacks, that should work *most* of the time
<alyssa> nod
<marcan> if sven's 4K patches fix all the IOMMU problems we should go with that by default, since it also enables android compat and more things
<alyssa> nod
<alyssa> I expect those to be a while to merge but it's probably for the best as a default long term
<marcan> if they work with thunderbolt devices and such, yeah
<marcan> though given that gem thing I'm now expecting a big explosion with eGPUs... which might put us in the same boat as macos, but for presumably another reason :p
<alyssa> gem thing?
<marcan> sven pointed out that GEM function using that dodgy IOMMU API that he didn't even implement
ZLSA has quit [Read error: Connection reset by peer]
rann has quit [Read error: Connection reset by peer]
phiologe has joined #asahi
WhyNotHugo has quit [Read error: Connection reset by peer]
esden has quit [Read error: Connection reset by peer]
austriancoder has quit [Read error: Connection reset by peer]
arnd has quit [Read error: Connection reset by peer]
ovf has quit [Read error: Connection reset by peer]
ZLSA has joined #asahi
WhyNotHugo has joined #asahi
rann has joined #asahi
ovf has joined #asahi
arnd has joined #asahi
austriancoder has joined #asahi
PhilippvK has quit [Ping timeout: 480 seconds]
esden has joined #asahi
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
thunfisch has quit [Quit: frrrp!]
analoq_ has joined #asahi
thunfisch has joined #asahi
analoq has quit [Ping timeout: 480 seconds]
<sven> didn't someone mention that the thunderbolt pcie controller has issues with unaligned reads/writes or something which makes egpu support tricky? (possibly corellium). i guess we'll see once thunderbolt comes up
gladiac has joined #asahi
gladiac is now known as Guest5799
gladiac has joined #asahi
Guest5799 has quit [Ping timeout: 480 seconds]
<kettenis_> hmm, I can't get the serial console to work with m1n1 on a macbook pro connected to a mini using macvdmtool
<kettenis_> rebooting works, but I don't see any serial output
<sven> do you use /dev/cu.debug-console as the tty dev? i think there's another one that won't work
<kettenis_> yup, using /dev/cu.debug-console
<sven> what kind of cable do you use? iirc i had a cable where rebooting worked but the serial console didn't because it hadn't connected those lines
<kettenis_> fairly confident that the cable is ok since it is the same type of cable that I use with the serial console I use with another m1n1 at home
<kettenis_> tried another cable as well
<sven> hm, no idea then. those were the only two issues i had
bps has joined #asahi
aleasto has joined #asahi
<kettenis_> at least the usb gadget thing works with OpenBSD ;)
<ar> kettenis_: this might sound stupid, but have you tried reversing the cable (as in, switch which end connects to which machine) or turning one of the ends upside-down?
<ar> usb-c cables are sometimes weird like that…
<kettenis_> yup, tried all permutations
<kettenis_> hmm, does m1n1 put the apple logo back on the framebuffer before loading a kernel/u-boot?
jthom[m] has joined #asahi
<marcan> kettenis_: yes
<marcan> well
<marcan> when chainloading, yes
<marcan> ah, and when loading a kernel too, yeah
<marcan> we should make it not do that for kernel boots, only for chainloads and such
<kettenis_> dunno, it just confused me a bit
<kettenis_> (trying to get u-boot working on the macbook pro)
<kettenis_> is there anybody here with a usb keyboard that I could borrow for a moment?
<kettenis_> oops, sorry
<kettenis_> wrong window ;)
Emantor has quit [Quit: ZNC - http://znc.in]
Emantor has joined #asahi
AnushervonTabarov[m] has joined #asahi
AnushervonTabarov[m] has left #asahi [#asahi]
AnushervonTabarov[m] has joined #asahi
aleasto has quit [Remote host closed the connection]
aleasto has joined #asahi
<alyssa> kettenis_: Sure! How far are you to Toronto? 😋
jbowen has joined #asahi
<kettenis_> a bit too far ;)
analoq has joined #asahi
analoq_ has quit [Ping timeout: 480 seconds]
<jbowen> Jared McNeill has NetBSD booting on the M1: https://twitter.com/jmcwhatever/status/1431575270436319235
<kettenis_> slacker! ;)
yuyichao has quit [Ping timeout: 480 seconds]
<kettenis_> just booted OpenBSD on the M1 macbook pro
<kettenis_> although I'm cheating with an external usb keyboard
<pipcet[m]> (I'm watching a 4k video on an m1 running linux right now, though I guess it's cheating because I'm using corellium code ;-) )
<jthom[m]> <jbowen> "Jared McNeill has NetBSD booting..." <- TempleOS when?
<marcan> pipcet[m]: pretty sure corellium didn't write any modesetting, display controller, or video decoding code :p
<marcan> jthom[m]: ToaruOS when? (cc klange)
<pipcet[m]> marcan: if we're being picky they did write one of the three lines of display controller code I'm actually using :P
<marcan> then you aren't watching a 4K video in 4K, since you need alyssa's actual display controller code for that
<pipcet[m]> marcan: it's still absolutely amazing what you guys are doing, and I wish I could give you money
<pipcet[m]> marcan: that's lines two and three.
<marcan> pretty sure it takes more than three lines to modeset 4K output on these machines
<kettenis_> marcan: any thoughts on how we're going to handle different device tree for different models in m1n1?
<marcan> kettenis_: just bundle them all in and pick the right one
<marcan> I'm thinking we could change the payload code to check a fdt's model string and reject it if does not match the adt
<marcan> the we can just cat them all together
<kettenis_> yeah, that makes sense
<kettenis_> the macbookpro has only a single pcie port and probing all three makes the machine unhappy
<marcan> yeah, we definitely need separate DTs of course
<marcan> the usual include/enable/disable patterns apply, this would be organized much like other linux dt platforms
<kettenis_> yup, t8103-j293.dts for the pro
<marcan> yup
<kettenis_> wonder if we need a shared .dtsi for the air and the pro
<marcan> might make sense
<marcan> and we should probably disable all the blocks by default
<marcan> and only enable what gets used in the downstream ones
<marcan> I mean, all the optional stuff like specific pcie controllers
<kettenis_> right
<marcan> what *is* the difference between the air and the pro? just the touch bar and maybe some thermal stuff?
<kettenis_> possibly
<pipcet[m]> er, that specific commit I mean.
<pipcet[m]> which adds a device tree
<j_ey> is there someone using picocom and vuart, and can test if exiting picocom causes the m1n1 shell to stop responding?
<marcan> I use picocom
<marcan> with the hV?
<marcan> *HV
<j_ey> yeah
<j_ey> one shell running run_guest, the other picocom, if I close picocom.. I cant ctrl+c in the m1n1 shell to stop the guest
<marcan> j_ey: works for me
<j_ey> exiting picocom with ^A^Q works, but not ^A^X, ^Q 'skips tty reset'
<j_ey> (so I'll just use ^A^Q from now on!)
<marcan> oh heh
<marcan> you're right, ^A^X breaks it completely
<marcan> I'll need to pull serial up again to debug that
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
<j_ey> marcan: oh good you can repro that, thought it was something in my setup
<j_ey> now I have to re-learn muscle memory for ^A^Q :)
<marcan> j_ey: oh it's dumb
<marcan> the ready thing is global
<marcan> we never split it when we added the secondary iface
<j_ey> I guess I'll wait for the fix, but I see `bool ready` in dwc3_dev_t, and I guess that should be in the pipe or endpoint struct instead
<marcan> j_ey: should be fixed
<marcan> :)
<j_ey> marcan: confirmed, thanks!
<marcan> j_ey: the distinction still matters, by the way
<marcan> if you use ^A^Q, vuart is still active and after the (huge) buffer gets filled, will stall there
<marcan> if you use ^A^X, vuart will be disabled and serial output dropped
<j_ey> oh, good to know, thanks
<marcan> this also means previously not opening vuart would stall the HV after the buffer gets filled, it shouldn't do that any more if you never open it, since it should default to closed
bps has quit [Ping timeout: 480 seconds]
<alyssa> Hmm I guess today is 4k day
<alyssa> Aside-- if someone is looking for low hanging asahi fruit, getting HDMI hotplug to work in m1n1 dcp.py might be waiting
<alyssa> I started but got distracted with kernel :-p
<alyssa> https://rosenzweig.io/hotplug.patch <-- this at least gets to not crashing
<alyssa> Essential for feature bring-up:
<alyssa> alyssa@sunset:~/Music$ mpv --no-video Legally\ Blonde\ The\ Musical\ \(Original\ Broadway\ Cast/
<pipcet[m]> alyssa: is it really the unix epoch that's used for get_calendar_time_ms?
<alyssa> yes.
<alyssa> or within a day of it anyway
<alyssa> unix epoch is used as the macos epoch so..
bps has joined #asahi
dsrt^ has joined #asahi
Erus_Iluvatar has quit [Remote host closed the connection]
Erus_Iluvatar has joined #asahi
Erus_Iluvatar_ has joined #asahi
Erus_Iluvatar has quit [Remote host closed the connection]
Erus_Iluvatar_ has quit []
Erus_Iluvatar has joined #asahi
X-Scale has joined #asahi
skoobasteeve_ has joined #asahi
skoobasteeve has quit [Ping timeout: 480 seconds]
phiologe has joined #asahi
PhilippvK has quit [Ping timeout: 480 seconds]
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
aleasto has quit [Quit: Konversation terminated!]
aleasto has joined #asahi
analoq_ has joined #asahi
erincandescent has quit [Remote host closed the connection]
erincandescent has joined #asahi
analoq has quit [Ping timeout: 480 seconds]
aleasto has quit [Ping timeout: 480 seconds]
analoq has joined #asahi
analoq_ has quit [Ping timeout: 480 seconds]
analoq_ has joined #asahi
analoq has quit [Ping timeout: 480 seconds]
analoq has joined #asahi
analoq_ has quit [Ping timeout: 480 seconds]
riker77_ has joined #asahi
riker77 has quit [Ping timeout: 480 seconds]
riker77_ is now known as riker77