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
zkrx has quit [Ping timeout: 246 seconds]
zkrx has joined #asahi
kettenis has joined #asahi
mort has quit [Quit: Ping timeout (120 seconds)]
mort has joined #asahi
Calchan has quit [Ping timeout: 260 seconds]
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 276 seconds]
Calchan has joined #asahi
<phire>
"N4 process that will enter risk production later this year and will be used for mass production in 2022."
<phire>
So way too late for the A15, but could be used for a M-series SoC early next year
<phire>
and from other rumours: "Apple has already booked the initial capacity of TSMC's N4 for its new-generation Mac series, the sources indicated."
marvin24 has quit [Ping timeout: 276 seconds]
marvin24_ has joined #asahi
jeffmiw has joined #asahi
jeffmiw has quit [Ping timeout: 246 seconds]
r0ni has joined #asahi
VinDuv has joined #asahi
lennylxx[m] has joined #asahi
VinDuv has quit [Quit: Leaving.]
phire has quit [*.net *.split]
scubasteve has quit [Ping timeout: 260 seconds]
frotizzz has joined #asahi
scubasteve has joined #asahi
Bublik has joined #asahi
frotizzz has quit [Quit: frotizzz]
herbas has joined #asahi
phire has joined #asahi
raster has joined #asahi
herbas has quit [Quit: herbas]
klaus has quit [Quit: Lost terminal]
klaus has joined #asahi
M1f4a9[m] has quit [Quit: Idle for 30+ days]
robinp has quit [Read error: Connection reset by peer]
Lightsword has quit [Quit: ZNC]
Lightsword has joined #asahi
akemin_dayo has quit [Ping timeout: 240 seconds]
<_andy_t_>
kettenis: Have you tried netbooting from U-Boot? I have a usb nic attached and have updated the config so I can use it, but it's very slow when used by an efi application.
<_andy_t_>
As far as I can tell it's because running the timers is slow in the transmit path
<kettenis>
_andy_t: no I haven't, but maz did at some point
<kettenis>
you mentioning timers rings a bell though
<kettenis>
the 5 second timeout at the OpenBSD bootloader prompt takes much longer than 5 seconds to expire
<_andy_t_>
Within u-boot the network is good, it can load the efi bootloader fast enough, it's just from within this bootloader I have issues
<kettenis>
which bootloader are you using?
<_andy_t_>
I have a local patch to switch from an efi timer to the virtual counter for time
<_andy_t_>
The FreeBSD loader
<_andy_t_>
Using the arm counter is better, but there's still a problem
bpye has joined #asahi
<kettenis>
the efi boot services code uses the same underlying drivers as u-boot itself
raster has quit [Read error: Connection reset by peer]
raster has joined #asahi
<_andy_t_>
I've seen efi_net_transmit take over a second to complete. The call to efi_timer_check seems to be the problem.
<kettenis>
u-boot doesn't use interrupts so if the bootloader doesn't make frequent EFI bootservices calls, timeouts may be delayed
_rjeffman has joined #asahi
rjeffman has quit [Ping timeout: 260 seconds]
_rjeffman is now known as rjeffman
rjeffman has quit [Client Quit]
rjeffman has joined #asahi
_rjeffman has joined #asahi
<_andy_t_>
This is in the middle of loading a few files from NFS, so there was a lot of network requests for the timers to be called
rjeffman has quit [Ping timeout: 260 seconds]
snalty has joined #asahi
<j`ey>
marcan: when's the next stream?
<marcan>
probably tomorrow; wanted to do one today but ended up busy this morning
<marcan>
had some errands
<marcan>
(just got back home)
<j`ey>
cool, hope i catch it then
<j`ey>
marcan: can you just give a quick recap of what the current status of loading macOS was. I watched some bits with patching macOS to turn (I think genter) into hvc. and then the last bit I watched was to try make hacr_el2 more finegrained to make the hv faster
mort has quit [Changing host]
mort has joined #asahi
<marcan>
j`ey: sprr/gxf is an issue; I already knew the gxf instructions cannot be trapped but it seems the sprr registers can not be trapped fine-grained. given that it's not trivial to emulate, so my next approach will be to just do it the "right" way and run m1n1 with SPRR enabled (and possibly partly or wholly in GL2), which allows the guest to do so too
<j`ey>
Thanks! I'll go read up on sprr then
<marcan>
read sven's blog :)
<marcan>
a priori it just means extending the pagetable code to properly support mapping at 16k granularity (right now we only do block maps in memory.c) so that we can properly map .text as r-x and .data as rw- (W^X which is enforced with SPRR on)
<marcan>
then gxf is more interesting; it's not clear exactly what it entails, but hopefully it won't be very hard. I'm thinking stuff like pointing the gxf exception base to the regular location; perhaps some registers need to be accessed differently and such
<marcan>
the details aren't clear but I think it should be easier than trying to trap and emulate the whole thing
<j`ey>
ah, I didnt realise gxf also had a different exception table
<marcan>
another approach would be to just patch macos to not use this (there may be some global vars you can just poke to trivially make it bypass it), but I want to avoid any dependencies on such mechanisms
<marcan>
nothing is patched in macos right now (I had a patching attempt but gave up, too many false positives to do statically; was considering doing it dynamically but I feel it'll be more work than just doing it right, and more brittle)
<marcan>
except the exception vectors get dynamically patched into hvcs, just so I can monitor guest exceptions
<marcan>
since it's the ony way to get any feedback on early problems
<marcan>
but I want to stop doing that
<marcan>
(which implies making sprr/gxf work, since those cannot be properly trapped from EL2)
<j`ey>
yeah, I thought that the patching didnt seem to clean
<j`ey>
ah right, you trap access to VBAR, I remember seeing that bit too (I assume so you can find the address to patch hvcs)
<marcan>
I don't (I can't)
<marcan>
instead I trap other stuff and then just read VBAR and see if it changed
<marcan>
then patch
<marcan>
:)
<marcan>
it's ugly
<marcan>
relies on some other trap firing before a crash happens
jabashque has quit [Quit: Connection closed for inactivity]
<marcan>
OTOH, since I have symbols now, it makes a lot more sense to just ditch that and statically patch the exception tables, which are at two well-known symbols
<marcan>
and then just stop doing that once things get far along enough
<marcan>
which they might already - serial works
<marcan>
so panics hopefully can go there
<marcan>
(originally I wasn't getting that far before a crash)
<j`ey>
are the symbols resolved by python or the m1?
<marcan>
python
<marcan>
that was last stream, all the fileset voodoo to get all the addresses fixed up and symbols loaded
<marcan>
so I have symbolized backtraces and such now
<pipcet[m]>
where are those streams? it sounds really interesting!
<marcan>
youtube.com/marcan42
<marcan>
I only have symbols for the core kernel (which is ~95% open source, except the "secret" m1 and gxf/etc bits)
<marcan>
so kexts will just show as name+offset, but at least I can still know what kext I'm in, even though I don't have more details
<marcan>
still better than no visibility
<marcan>
pipcet[m]: by the way, chainload.py smp works fine now, though I haven't committed/pushed that yet
<pipcet[m]>
I tried the latest version you pushed, no luck here. Glad it's working for you :-)
<pipcet[m]>
looking forward to ditching that hack
<pipcet[m]>
(currently installing the macos CC so I can communicate between the linux kernel I have running on CPU7 and the macos system on CPU0. Turns out if you only give macos 4 GB of RAM installation takes forever)
<marcan>
pushed
<pipcet[m]>
thanks!
<maz>
kettenis: I've seen the same issues as _andy_t_. booting the kernel as an EFI application from the kernel is fine. booting an intermediate bootloader (such as ... err... grub) results is something horribly slow and unreliable.
<pipcet[m]>
ah, that makes sense. I wonder why iboot didn't do that for us.
<maz>
kettenis: I parked that for the moment, specially given that I'm out of cycles...
<balrog>
marcan: the KDK comes with symbols for a handful of kexts but not the interesting ones
Chainsaw has joined #asahi
vimal has quit [Quit: Leaving]
Lightsword has quit [Quit: ZNC]
Lightsword has joined #asahi
<kettenis>
I fear the u-boot usb stack isn't great
choozy has joined #asahi
<kettenis>
but if performance is worse than on other arm64 boards that use u-boot, this is something I should look into
<pipcet[m]>
hehe. I have a useful Linux system with no IRQs. It just reads /dev/mem, waits for commands that I put there from macos, and executes them, allowing me to access physical memory locations that I wouldn't otherwise get at.
_rjeffman is now known as rjeffman
<pipcet[m]>
marcan: I can confirm that SMP works here with your latest code :-)
ephe_meral1 has joined #asahi
akemin_dayo has joined #asahi
<maz>
kettenis: I don't think this is related to the USB stack. it is definitely good enough to load stuff from the network pretty quickly.
<maz>
kettenis: the slowdown happens if running an EFI app under u-boot.
<maz>
and I don't see this with other systems that use u-boot.
<maz>
my bet is on a screaming interrupt.
Izumoo has quit [Quit: Konversation terminated!]
grange_c has quit [Quit: Ping timeout (120 seconds)]
grange_c has joined #asahi
Hexagon has quit [Remote host closed the connection]
Hexagon has joined #asahi
<kettenis>
hmm, the default irq and fiq handers in u-boot print stuff
<kettenis>
so unless i'm missing something, it can't be interrupts
<maz>
kettenis: I'll try and trace things a bit next week (that's what holidays are for...)
<kettenis>
wonder if it is the bounce buffer implementation that may be used for the EFI calls
<_andy_t_>
I've added timing info to u-boot & found r8152_eth_recv can be slow
<maz>
how slow?
<_andy_t_>
It can take over 1s
<maz>
huh...
<maz>
I'm using a vintage AX88772, which works well enough... r8152 is awfully modern compared to it.
<_andy_t_>
It seems to be spending time in usb_ether_receive