marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | Not ready for end users / self contained install yet. Soon. | 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
skipwich_ has joined #asahi
skipwich has quit [Read error: Connection reset by peer]
<rkjnsn[m]>
Hmm… it looks like the firmware in the Apple driver for the Broadcom 43602 rev. 1 expects a different bring-up sequence than the Linux driver uses.
<rkjnsn[m]>
Looking at vfio traces, the Linux driver polls region2+0x26fffc (the last four bytes of the card's RAM), expecting the firmware to set it to a pointer to a shared memory region once it has booted. The Monterey driver, however, polls region2+0x26f0a8, which appears to merely change from a 0 to a 1 when the firmware is ready.
Glanzmann has quit [Quit: EOF]
<rkjnsn[m]>
The Apple driver also puts the nvram data in a different spot, starting at region2+0x26a0a4, rather than at the end of RAM.
darkapex3 has quit [Ping timeout: 480 seconds]
jeffmiw has quit [Ping timeout: 480 seconds]
eroux has joined #asahi
darkapex has joined #asahi
MajorBiscuit has joined #asahi
chadmed has joined #asahi
<rkjnsn[m]>
I guess we're fortunate that the firmware for the T2 and M1 cards uses the same approach as the Linux driver expects. I wonder why the ABI Apple uses for the older cards is so different.
<jannau>
is 'kmutil configure-boot --raw' supposed to work with macos 11? It does not with 11.4 and 11.5 installer stubs or a full 11.6 system. Main macos is 12.2 beta, on a mac mini
the_lanetly_052__ has joined #asahi
<rkjnsn[m]>
I might be misremembering the earlier discussion, but I seem to recall that I read for that combination the trick was to use --raw to make kmutil happy, but actually give it the macho and not the bin, as the iBoot for 11 doesn't support raw, and will parse it as a macho regardless of the --raw option.
<jannau>
so far only minimal testing with the 11.5 firmware, which more or less pointless since that has a working framebuffer
<jannau>
it doesn't work with --lowest-virtual-address 0 --entry-point 2048, I have hoped those are ignored with a macho payload
<jannau>
not sure if it's worth spending time on this. I have a working dcp driver and it has to be updated to the 12.0/12.1 ABI anyway to be useful
<rkjnsn[m]>
Yeah, I thought marcan had said those were ignored by older iBoot versions, but I'm not sure if there was anything else special one needed to do to make it work.
Glanzmann has joined #asahi
<Glanzmann>
jannau: Have you managed to get the mini with hdmi output working again?
<_jannau_>
Glanzmann: it works for me with the 11.5 installer stub on a mac mini which was not updated to 12.1
<Glanzmann>
~.
<Glanzmann>
jannau: I see. I have already updated.
aleasto has joined #asahi
<Glanzmann>
For me the old one was working, until I deleted the stub partition ...
<_jannau_>
I think HDMI output should work with any macos 11 stub but I don't know how to configure a custom boot object for that from the 12.2 (and probably 12.1) recovery
the_lanetly_052___ has joined #asahi
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
<kettenis>
the name rtkit is already entrenched in OpenBSD ;)
<marcan>
lol
<sven>
rtkit it is then :D
<marcan>
kettenis: see this is why y'all are too fast :D
<sven>
knowing apple it may also be called both :D
<sven>
because iirc there’s also RTBuddySysogEndpoint and stuff like that
<marcan>
actually, you know what
<marcan>
only DCP talks about AFK
<marcan>
... did they rewrite the entire thing for DCP?
<marcan>
I swear I'm getting the feeling everything elses uses RTKit and is written in C
<marcan>
while DCP is a giant pile of C++ including all the "rtkit" endpoint support
<sven>
lol
<sven>
Rtbuddy should implement the system endpoints fwiw
<marcan>
yeah
<sven>
and that’s used for everything I looked at
<marcan>
well, rtbuddy is the macos side isn't it?
<sven>
yes
<marcan>
yeah
<marcan>
so I think there are two implementations IOP-side lol
<sven>
lol
<marcan>
of at least part of it anyway
<ChaosPrincess>
marcan: as someone who mostly comes from x86_64 experience, are there rmw instructions on aarch64, is it possible that one is used to target spi mmio, and does the hypervisor support emulating them?
<kettenis>
emulating mmio is not as messy as on x86, but there still are more load.store instructions that one would like ;)
<ChaosPrincess>
x86 is just a mess in general, i once wrote a generic library to divert functions and i dont think im doing that ever again :P
<j`ey>
ChaosPrincess: im assuming the error from `readModifyWrite` was from the xnu logs?
<ChaosPrincess>
xnu logs
<j`ey>
because the HV prints if it couldnt emulate something
<marcan>
the hv will trap if it fails to emulate
<Glanzmann>
jannau: That is also my problem.
<ChaosPrincess>
trap as in?
<ChaosPrincess>
inject an interrupt?
<j`ey>
go to the HV repl
chadmed has quit [Remote host closed the connection]
MajorBiscuit has joined #asahi
off^ has quit [Ping timeout: 480 seconds]
off^ has joined #asahi
the_lanetly_052___ has quit [Remote host closed the connection]
<j`ey>
for those using X11, did you do anythin with resolution/scaling?
the_lanetly_052 has joined #asahi
<mps>
j`ey: with simpledrm?
<Glanzmann>
j`ey: In Firefox I zoom.
<Glanzmann>
j`ey: In xterm I use 20 pixel font.
<Glanzmann>
That's it.
<mps>
ah in applications? I set DPI in .Xresources
<j`ey>
mps: with simplledrm yes
<j`ey>
Glanzmann: i set that, still too small for me :(
<mps>
j`ey: I have this `echo 'Xft.dpi: 192' | xrdb -merge` in .xinitrc
<mps>
96*2
<mps>
default DPI is 96
<j`ey>
mps: will give that a go
<mps>
this is 'bug' in old xorg which was fixed in 21.1.0 and a lot of people cried because they have workarounds for bug, and then fix is reverted to be old bug in 21.1.1
<mps>
fun with open source :)
<Misthios>
it became a feature
<mps>
Misthios: 'bug is feature' moto
Dcow has joined #asahi
yuyichao has quit [Ping timeout: 480 seconds]
aleasto has quit [Quit: Konversation terminated!]
aleasto has joined #asahi
aleasto has quit []
aleasto has joined #asahi
aleasto has quit []
aleasto has joined #asahi
aleasto has quit []
aleasto has joined #asahi
yuyichao has joined #asahi
aleasto has quit [Remote host closed the connection]
<Glanzmann>
j`ey: That is -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1
<j`ey>
Glanzmann: the screenshot is readable on my other laptop. I tried with xterm*font: 10x20, which I believe is that font you said, but it's still quite small
<j`ey>
jannau: btw are you testing your spi stuff with linux.py or with hv?
<j`ey>
jannau: Ive gotten that SPI boot failure a few times, even with your patch
<j`ey>
jannau: changing the waiting jiffies to 1000 from 500 seems to have helped, will reboot a few more times
<kettenis>
timing wil be a bit off under the hv
<j`ey>
yup, and it's probably fine to bump that number a bit anyway
<kettenis>
giving it a wee bit more margin shouldn't hurt
<Glanzmann>
j`ey: This was a fullscreen screenshot on my macbook air so if you open that in firefox and press f11 you get the same look & feel.
<jannau>
j`ey: I test mostly with chainloading m1n1 + linux image payload. it's much faster here than the timeouts but bumping the timeouts up should not be a problem. it will make a unsuccessful probe take longer in the worst case
<j`ey>
Glanzmann: ok, I will have to install some kinda image viewer at some point then (or ff)
<j`ey>
jannau: with !smp it seemed fine, but as you say, it's only unsuccessful probes that will be effected
<jannau>
HV without tracing is not even close at timing out on my mbp14
<j`ey>
it seemed fine and then it timed out 2-3 times in a row
<jannau>
do we stop the guest time with !smp?
<j`ey>
im not sure what happened with the guest time stuff, i think it was turned off at some point?
<j`ey>
build times for kernel: x86 desktop: -j70 1min, macbook air: -j12 2min6s
<j`ey>
that's.. pretty good, and the m1 is under the hv
<Glanzmann>
with 2ghz.
<jannau>
is the -j70 close to the number of smt threads? a significant amount of the 1min will be the final linking of the kernel image though. test with touching a single file and rebuild
<j`ey>
jannau: I have 55 threads I think it is
<Glanzmann>
j`ey: What kind of desktop do you have? I compile on 16 core ryzen 5950X. It takes like 2 minutes, but I'm building a debian package.
the_lanetly_052 has quit [Ping timeout: 480 seconds]
<j`ey>
it's a Lenovo p720 maybe? something like that, it's my work machine
<j`ey>
was mainly just a rough test, since I just got everything working enough to try it out :)
<j`ey>
jannau: uh, just failed for me with linux.py and the 1000 timeout :/
<Glanzmann>
Okay, If I push my ryzen, I get: real 0m17.643s
<Glanzmann>
for time eatmydata make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j64 Image.gz modules dtbs
<j`ey>
17s from scratch seems.. too fast?
<Glanzmann>
j`ey: Let me check if ccache was involved.
<j`ey>
jannau: raised the timeout to 5000, and still fails
<jannau>
j`ey: I suspect the packet the driver is waiting for doesn't arrive at all
<Glanzmann>
j`ey: That was ccache helping me, without it I get 2m18.636s on the ryzen.
jmr3 has joined #asahi
<jannau>
j`ey: please uncomment the '#define DEBUG 2' at the top of the file and append 'debug' to the kernel command line
<j`ey>
Glanzmann: on your air, you use the m1n1 proxy + linux.py to boot right?
jmr2 has quit [Ping timeout: 480 seconds]
<j`ey>
jannau: only problem is getting logs.. since I dont have uart
<Glanzmann>
j`ey: Sometime, but at the moment I mostly use m1n1+u-boot -> grub -> linux + initrd.
<Glanzmann>
Sometimes*
MajorBiscuit has quit [Quit: WeeChat 3.3]
<jannau>
j`ey: `dmesg | grep spi` after booting if you have ssh
<j`ey>
jannau: oh right, i forgot I had wifi now :D
<jannau>
j`ey: increase SPIHID_DEF_WAIT to 100 ms or so
<j`ey>
ok
<j`ey>
jannau: will report later tonight
jeffmiw has joined #asahi
<j`ey>
jannau: 100ms SPIHID_DEF_WAIT works
off^ has quit [Ping timeout: 480 seconds]
off^ has joined #asahi
<j`ey>
hm, I guess m1n1 is good at getting out of the way in general, no noticable difference when building a kernel without hv
<j`ey>
I suddenly seem to have issues with the wifi though, I thought it was related to low battery.. but I charged and it's happening :/
<j`ey>
it seems to just drop, and then randomly work again
jeffmiw has quit [Ping timeout: 480 seconds]
<Glanzmann>
j`ey: The wifi for me is rock stable.
<Glanzmann>
But I never used the hv.
<Glanzmann>
j`ey: Even when moving multiple GB per data. And I once did a 24 hour stress test, not one iperf3 meassurement was not giving the expected performance.
<j`ey>
Glanzmann: yeah, that's why i'm confused :) Im going to leave ping running a bit, see if it drops again
<Glanzmann>
j`ey: I ran this for 24 hours: tg.st/u/wifitest.sh Results: tg.st/u/wifi.log.gz
<j`ey>
Glanzmann: Im just running: while 1 ; date ; ping google ; sleep 30 ; done
<j`ey>
should be enough
<j`ey>
yup, it died
<Glanzmann>
ugh.
<j`ey>
only took 3mins
<Glanzmann>
j`ey: Drop the hv.
<j`ey>
it came back again!
<j`ey>
I did get that brcmf_p2p_send error again, so it could be something weird with my wifi or setup or something
<j`ey>
and it dropped off again, and I saw that p2p error again..
jmr2 has quit [Quit: Konversation terminated!]
jmr3 has joined #asahi
<j`ey>
I can't seem to reproduce it again, pinging away for 30mins+ without any issues :/