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
richbridger has quit [Remote host closed the connection]
richbridger has joined #asahi
<brentr123[m]>
Wow I am running arm64 windows through parallels and it is running at near full speed
<brentr123[m]>
Amazing
<marcan>
brentr123[m]: considering how much faster the M1 is than most arm64 windows machines, it ought to be running *faster* than "full" speed :P
<marcan>
(and it'll probably run faster on Linux once the graphic bits are done, unless Apple and Parallels implement vGIC support before then :p)
<quarkyalice>
could you pass an external GPU through to Linux?
<quarkyalice>
well that was worded poorly
<quarkyalice>
could you use an external GPU with Linux? and/or pass it through to a VM
phiologe has joined #asahi
PhilippvK has quit [Ping timeout: 480 seconds]
bgb_ has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
marvin24 has joined #asahi
Namidairo has quit [Remote host closed the connection]
<jannau>
any thoughts of updating the cache last, i.e. after the handlers have run? I want to use to skip logging uninteresting events
<marcan>
registers may have overlapping sparse ranges
<marcan>
why have all the IRQ groups as separate arrays and not one combined one?
<marcan>
oh, because padding?
<jannau>
fix pushed
<marcan>
lgtm
<jannau>
I think the irq groups could use just a single range. i.e. the space between them is unused and the design allows up to 512 pins
<marcan>
yeah, I think so
<jannau>
I just decided to duplicate code instead of calculating the group and pin from the index
<marcan>
are there really 7 IRQ groups?
<marcan>
is that because 0 is "no group" or so?
<jannau>
yes, 7 seems to be no group and the gpio chip has 7 AIC irqs in the ADT
<marcan>
fair
<marcan>
I don't like the irq group duplication but I ran into something similar with DART; I'll see about adding explicit register lists, so that combined with the array support we can have 2D arrays
<marcan>
fine for now though
<marcan>
or maybe I can have a "shape" for register arrays
<marcan>
that might be cleaner to implement (though less flexible)
<marcan>
yeah, I think I know how I want to do it
<marcan>
going to stream for a bit now
VinDuv has joined #asahi
zarvox has quit [Ping timeout: 480 seconds]
thunfisch has quit [Quit: UAAARRR!]
skali is now known as skali_
skali_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bgb_ has quit [Read error: Connection reset by peer]
bgb_ has joined #asahi
bytefire_ has joined #asahi
<bytefire_>
hi
<j_ey>
hi
<ar>
hi
aleasto has quit [Quit: Konversation terminated!]
<bytefire_>
just beginning with asahi after watching (60% so far) "m1n1 Hypervisor recap" video. is there a special way to flash own hypervisor or it's same as booting with recovery image and in that image switching to EL2?
<j_ey>
it boots at EL2 by default
<bytefire_>
i see, thanks. do we know the early boot sequence? e.g. which EL reset vector starts in and what code is that?
<j_ey>
not sure, but iBoot handles all that for us
<bytefire_>
right. i read about gxf (again very early basic knowledge). i wonder if it starts at guarded EL2
<bytefire_>
is early boot firmware out of scope for asahi?
<j_ey>
yes
<bytefire_>
got it
<j_ey>
and no, im pretty sure guarded exec is not enabled, otherwise marcan would have to dealt with that ages ago, but it wasnt that long ago they got guarded exec working
<bytefire_>
interesting. my guess was based on that standard arm-v8 cpus boot at most privileged level el3. so equivalent would be guarded-el2 in m1.
<bytefire_>
i mean the article says os expects gxf to be working
<marcan>
bytefire_: the GL levels are not part of the normal ELx order
<marcan>
each GLx is a side level for ELx
<marcan>
and can be enabled by ELx, and locked
<bytefire_>
ohh...
<marcan>
at which point it is more privileged than ELx, but it has to be bootstrapped like that first
<bytefire_>
"has to be bootstrapped like that first" -- you mean it's some boot time setting?
<j_ey>
its more priveleged, only due to the way permission flags work, it has the usual priveleges otherwise
<bytefire_>
i see
<bytefire_>
are iommu's aware of guarded mode?
<bytefire_>
is there some place where i can read more about gxf?
<j_ey>
I dont think iommu's have any relation to gxf
<j_ey>
you could look at m1n1's gxf code
<bytefire_>
i see. thank you, will do. there's a quickstart guide too :)
<bytefire_>
by iommu's being gxf aware, i meant can peripherals act in guarded mode. but i guess i need to understand gxf better because currently i keep equating it to TZ
<svenpeter[m]>
It’s not TZ
<svenpeter[m]>
It’s literally the same as ELx but with a different understanding of pagetable permissions
<svenpeter[m]>
And iommus are not aware of gxf. They have their own page tables anyway
<bytefire_>
i see
<j_ey>
marcan: did you see my q (and self-answer) about the data.id thing last night? just to confirm I understood
<marcan>
j_ey: yeah, you're correct :)
<j_ey>
great!
choozy has joined #asahi
<bgb_>
about arduino-based uart: if I use 1.8v uart for host, then I must step down the TX voltage with resisters, right?
bgb_ has quit [Ping timeout: 480 seconds]
<marcan>
yes
<sven>
urgh. i can't wait for linux support on this m1. i just connected a 4k external screen and it just doesn't work correctly :/
<sven>
it goes to black for a brief moment every few seconds
<j_ey>
sven: my external screen didnt work with my MBA either
<j_ey>
I cant remember exactly, it just said something like 'billboard device'
<sven>
oh, it recognizes the screen just fine. even the 4k resolution
<sven>
it's just rather unstable :/
<kettenis>
marcan: regarding the side-cores, the S
<j_ey>
mine didnt work at all
<kettenis>
the SMC one is already running, but the NVMe one isn't
<ar>
sven: that might be an issue with your cable or (if you use one) adapter
<marcan>
kettenis: I think DCP is already running
<ar>
sven: I've experienced that with linux and windows on normal pcs with usb-c → displayport adapters too
<kettenis>
marcan: given that you havr a display going, it would be logical for it to br running already ;)
<_jannau_>
same could be said about nvme given that i-boot already loaded the kernel from it
<kettenis>
I expected the NVMe one to be running as well, since iBoot reads from the NVMe
<kettenis>
but apparently they shut it down before handing control to the "kernel"
<sven>
ar: nope, the same cable works just fine on my linux laptop
<sven>
i could maybe try a usb-c -> hdmi adapter though
<sven>
but this should just work
<sven>
(it also feels like i'm in the wrong universe: since when do external screens work just fine on linux but have issues on macOS? :D)
<dhewg>
since companies started caring more about telemetry and data hoarding than actual features?
<ar>
sven: i have one usb-c -> dp + pd-passthrough adapter that behaves like yours, and one that works
<ar>
sven: (actually i have two of the kind that works)
<ar>
sven: and the one that doesn't work reliably, doesn't work with my thinkpad x13 (amd renoir apu) and mbp13 m1 from the company i work for now
<ar>
and those that work, work
<sven>
the cable i have works with my old dell laptop and my company thinkpad. it just doesn't work with the m1 :/
<_jannau_>
same here, I have lenovo usb-c dp adapter which works and a second one which doesn't work on the mac mini
<mini>
sven: that's odd. I'm using a 5k and a 4k external off of a mac mini. it was buggy as anything with the early OS releases, but stable now