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
tsida has joined #asahi
bgb_ has joined #asahi
brent has joined #asahi
<brent>
test
<brent>
just testing irssi
brent has left #asahi [asahi]
<brentr123[m]>
so used to the client called element, wanted to try something else
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
<bloom>
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 483 seconds]
bgb_ has quit [Quit: WeeChat 3.0.1]
Graypup_ has quit [Quit: meow]
Graypup_ has joined #asahi
bgb has joined #asahi
<bgb>
marcan: how about the "Flexible USB-PD Debug Interface" mentioned in doc?
<marcan>
bgb: it's kind of back burnered now that the dwc support in m1n1 and hypervisor make it largely unnecessary for people
<marcan>
it'll happen, but I want to prioritize getting the gpu and other kernel drivers on track
SocioProphet[m] has joined #asahi
VinDuv has joined #asahi
<jannau>
rebooting by command is very convenient compared to pressing the power button
<SocioProphet[m]>
I concur doctor
<marcan>
jannau: with the hv you can reboot by command (or it reboots itself if it crashes, with the wdt)
<marcan>
clearly I need to make a script to automatically run linux.py under the hv and clean up the vuart so it works with the linux driver and then y'all have no excuse to just always run linux virtualized :) (okay I also should make SMP work)
<marcan>
actually wait, I don't actually have a proper reboot command do I
<marcan>
:-)
<marcan>
whoops
<Dementor[m]>
<marcan "actually wait, I don't actually "> It's ok we'll forgive you
<marcan>
it's like 2 lines of code! you need to ask for these things!
<marcan>
pushed; `reboot` at the hypervisor console will now do a hard reboot and exit the script
<marcan>
jannau: btw, have you tried the "turn on on power failure" thing in the macos settings? it might make for a simpler hard reboot by momentarily removing power, instead of having to hold down the power button for a while
VinDuv has quit [Quit: Leaving.]
<_jannau_>
marcan: I have a fusb302 breakout board and vdmtool
<marcan>
ah, fair :)
<bgb>
I am running m1n1 proxyclient on Macos(M1), successfully boot to virtualized macos if I disable all mmiotrace. however, if enable one of them, python client will fail due to lack of "aarch64-linux-gnu-gcc ...".
<marcan>
you need a crosscompiler for the disassembler to work
<marcan>
do you have a stack trace? that shouldn't happen unless you get an exception
<bgb>
forget one thing: also commented "self.u.print_exception(code, ctx)" in hv.py
<_jannau_>
I saw occasionally PMC irq quite early in the boot process
<marcan>
quite likely
<marcan>
but those shouldn't end up in python?
<marcan>
oh wait, they do
<marcan>
yeah we should just handle the PMC IRQs properly
<marcan>
_jannau_: does that actually work? the reason I originally wanted to do it disabling FIQs was that I thought if you just cleared IACT it would come back unless the counters were cleared too, and then you'd end up in a fiq storm
<_jannau_>
I thought so too but it does work
<marcan>
you also need to actually deliver the FIQ
<marcan>
in hv_update_fiq
<marcan>
also the comment is out of date :)
<marcan>
I guess right now it works because whenever the guest gets a timer irq it'll handle the pmc stuff too anyway
<bgb>
marcan: I think there is not an aarch64-xxx cross compiler for macos(m1), right?
<alessandrorzz[m]>
There is a vm with arch precompiled
<marcan>
a native gcc/binutils will work, but you need to pass ARCH= (empty) so it doesn't use the prefix if you don't have the prefixed tools in your PATH
<marcan>
I should just figure out some other way of doing this than the current shellout hack...
<marcan>
maybe Keystone?
<marcan>
(and Capstone)
<bgb>
well, beyond cognition, again...
norwoodites has joined #asahi
pinskia has quit [Remote host closed the connection]
<bgb>
do you mean the openstack component?
<jannau>
I think I have to reset counters. clearing IACT probably does not work. macos seems to be fast enough to reset them so I get only a single irq no matter what I do
<marcan>
jannau: so just turn off irq delivery instead
<marcan>
and shadow that
<marcan>
you can reenable it as soon as macos clears IACT
<marcan>
then the logic for update_fiq is IACT in the real register && macos has enabled FIQs
bisko has joined #asahi
<maz>
kettenis: yup, I'll try and get to it.
bgb has quit [Ping timeout: 480 seconds]
bgb has joined #asahi
pugguu has joined #asahi
norwoodites is now known as pinskia
bgb_ has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
marvin24_ is now known as marvin24
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
EER has joined #asahi
choozy has joined #asahi
choozy has quit [Remote host closed the connection]
pugguu has quit [Read error: Connection reset by peer]
pugguu has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
bisko has joined #asahi
pugguu has quit [Ping timeout: 480 seconds]
pugguu has joined #asahi
choozy has joined #asahi
d18n has joined #asahi
pugguu has quit [Ping timeout: 481 seconds]
pugguu has joined #asahi
EER_ has joined #asahi
EER has quit [Ping timeout: 480 seconds]
pugguu has quit [Remote host closed the connection]
pugguu has joined #asahi
bgb_ has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
choozy has quit [Ping timeout: 480 seconds]
pugguu has quit [Remote host closed the connection]
pugguu has joined #asahi
<yuyichao_>
marcan: does the HV in m1n1 allows running linux with a usable console without special hardware setup? (and any document on using it?)
bgb_ has joined #asahi
<marcan>
yuyichao_: it will once I improve the vuart to support what linux needs
<marcan>
right now it's kinda dumb
bgb_ has quit [Ping timeout: 480 seconds]
ave has quit [Quit: sayonara o/]
ave has joined #asahi
ave has quit []
ave has joined #asahi
pugguu has quit [Ping timeout: 480 seconds]
pugguu has joined #asahi
hspak3 has joined #asahi
bgb_ has joined #asahi
hspak has quit [Ping timeout: 480 seconds]
hspak3 is now known as hspak
bgb_ has quit [Ping timeout: 480 seconds]
_whitelogger has joined #asahi
choozy has joined #asahi
bgb_ has joined #asahi
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
pugguu has quit [Remote host closed the connection]
pugguu has joined #asahi
bisko has joined #asahi
pugguu has quit [Read error: Connection reset by peer]
bgb_ has quit [Ping timeout: 480 seconds]
pugguu has joined #asahi
bgb_ has joined #asahi
hspak1 has joined #asahi
hspak has quit [Read error: Connection reset by peer]
hspak1 is now known as hspak
bgb_ has quit [Ping timeout: 480 seconds]
pugguu has quit [Read error: No route to host]
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
pugguu has joined #asahi
pugguu has quit [Read error: Connection reset by peer]
pugguu has joined #asahi
pugguu has quit [Read error: Connection reset by peer]
pugguu has joined #asahi
pugguu has quit [Ping timeout: 484 seconds]
pugguu has joined #asahi
bgb_ has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
artemist has joined #asahi
Izumoo has joined #asahi
choozy has quit [Ping timeout: 483 seconds]
bgb_ has joined #asahi
pugguu has quit [Ping timeout: 480 seconds]
pugguu has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
pugguu has quit [Ping timeout: 480 seconds]
bgb_ has quit [Ping timeout: 480 seconds]
pugguu has joined #asahi
pugguu has quit [Read error: Connection reset by peer]
pugguu has joined #asahi
pugguu has quit [Ping timeout: 481 seconds]
bgb_ has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
VinDuv has joined #asahi
d18n has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
choozy has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
skoobasteeve_ has joined #asahi
skoobasteeve has quit [Ping timeout: 480 seconds]
EER has joined #asahi
EER_ has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
klaus has quit [Quit: WeeChat 3.1]
klaus has joined #asahi
<Emantor>
marcan: reboot is very handy, thanks :-)
bgb_ has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
pastly-antispam has quit [Quit: time for a tune up]
pugguu has joined #asahi
bgb_ has joined #asahi
pastly-antispam has joined #asahi
zopieux has quit [Ping timeout: 480 seconds]
bgb_ has quit [Ping timeout: 480 seconds]
zopieux has joined #asahi
bgb_ has joined #asahi
<Emantor>
> barebox@Apple M1 Mac Mini (J274):/ (with only some slight modifications to the cache functions to run within the hypervisor, have not UART otherwise.)
bisko has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
<bloom>
bareox?
<sven>
alright, looks i can extract the bypass configuration from dma-ranges and i can also use def_domain_type to enforce bypass mode from within the DART driver if booting a 4k pagesize kernel :)
<bloom>
waow
<sven>
feels much less like a hack now
<bloom>
what's the tradeoff for bypass mode again?
<bloom>
no thunderbolt?
<sven>
yeah, thunderbolt with bypass mode is a very bad idea
<bloom>
s/with bypass mode //
<bloom>
FTFY
<sven>
:D
<bloom>
type-C or bust
<j_ey>
why sven?
<sven>
it should actually been *without :D
<Emantor[m]>
Wee for Thunderbolt hardware messing with your gpu memory \o/
<sven>
either way, we can be confident now that the dart bindings work with way and will continue to work if we can teach the kernel to handle 16k iommu pages with 4k cpu pages
<sven>
*this way
<sven>
<sven> it should actually been *without :D <-- scratch that. i'm just confused.
<sven>
j_ey: just google thunderbolt dma attack or something like that
<j_ey>
ok
<sven>
essentially any device attached to thunderbolt would have access to all memory
<j_ey>
that seems reasonable to want behind an IOMMU
<brentr123[m]>
You have to have physical access for malicious intent using that
<sven>
yes, still not something i'd comfortably enable in production
<sven>
btw. did anyone check if you can unplug devices on the usb-c ports when using the corellium kernel?
<sven>
well, unplug and then reattach
bgb_ has joined #asahi
<pipcet[m]>
sven: I'm using something based on the Corellium kernel (at https://github.com/pipcet/pearl), so it's possible I broke it somehow, but no, doesn't work. It does if I manually unbind/rebind the driver.
<sven>
hm, ok. so it's probably no the usb pd chip then
<sven>
*not
<pipcet[m]>
can we work around it by resetting the device whenever connection status changes?
<sven>
i'd rather just figure out how to do it properly
<pipcet[m]>
of course, but having a fallback plan doesn't hurt.
<sven>
sure
bgb_ has quit [Ping timeout: 480 seconds]
<pipcet[m]>
okay, that doesn't appear to trigger in all cases, either.
pugguu has quit [Read error: Connection reset by peer]
pugguu has joined #asahi
<marcan>
sounds like a good first mmiotrace handler; i2c dumps
<marcan>
should be easy enough
<sven>
yeah, i just need to make it work
<sven>
first time i tried i hit some weird pmgr panic
<sven>
not sure if i used the right kernel version though
pugguu has quit [Read error: Connection reset by peer]
pugguu has joined #asahi
pugguu has quit [Read error: Connection reset by peer]
pugguu has joined #asahi
<bloom>
pipcet[m]: oh, this is the frist i'm hearing of pearl, looks nice :o
bgb_ has joined #asahi
pastly-antispam has quit [Remote host closed the connection]
<bloom>
how are you finding that for day-to-day use?
pugguu has quit [Read error: Connection reset by peer]
pugguu has joined #asahi
<pipcet[m]>
more usable than macos, but I don't think that's saying much ;-)
<bloom>
I getcha ;-)
<bloom>
i admit i'm really not convinced about the whole kexec thing, seems newfangled for me
<pipcet[m]>
it's been around for 20 years or so
pugguu has quit [Read error: Connection reset by peer]
pugguu has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
<pipcet[m]>
do you see problems with it apart from being newfangled? I admit it is still unusual, but it is very nice to be able to do the ADT->FDT transformation in userspace (or maybe I'm just horrible at writing code that runs without debugging in the murky depths of prebootland)
<bloom>
I'd have to look more closely at your architecture
<bloom>
The showstopper for me for these types of repos (and I've been through a lot of them for Chromebook linux) is the difficulty in auditing the source
pugguu has quit [Remote host closed the connection]
pugguu has joined #asahi
<jannau>
marcan: except that we currently hide both usb-c ports and need one for mmiotrace
<marcan>
jannau: you can try hiding just one, if that's broken it shouldn't be too hard to fix
EER has quit [Remote host closed the connection]
bgb_ has joined #asahi
<marcan>
jannau: fyi, “We shouldn’t support dual-booting because iBoot does” isn't a philosophical issue, it's a "your stuff is going to break SEP usage once we start supporting that properly" issue
<marcan>
two OSes using the same SEP storage/context is not a good idea
<marcan>
but hey, whatever floats your boat :p
pastly-antispam has joined #asahi
<marcan>
the correct way to support dual-booting without the "hold down the power button" issue is to have whatever boot picker you want to have, but actually clean reboot into the new OS (via nvram var) the same way 1TR does
<jannau>
marcan: you mean pipcet[m] re dual booting
<marcan>
er, yeah, sorry
<marcan>
just woke up
<marcan>
pipcet[m]: ^
bgb_ has quit [Ping timeout: 480 seconds]
VinDuv has quit [Quit: Leaving.]
<jannau>
just hiding one usb-c seems to work but my current PM irq changes seem to cause a FIQ storm in mac os
<sven>
:D
<sven>
would be lovely if you could figure out that usb replug issue. i suspect it's either the i2c chip or possibly one of the other interrupts in the drd node
<sven>
(well, that or some magic bit that needs to be poked somewhere in the phy regs)
<sven>
probably the first four are just the "normal" interrupts but the last one looks supicious
<jannau>
the hook for 0x23d280090 made it slow
<pipcet[m]>
marcan: thanks for pointing that out
<jannau>
second usb-c port is useable in mac os but my perf monitor irq handling is broken
bgb_ has joined #asahi
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bgb_ has quit [Ping timeout: 480 seconds]
<jannau>
bug fixed but we probably have to account for cycles spent in the hypervisor
<jannau>
the guest is noticable slower now that I deliver pmu irqs
<sven>
fast enough to replug a usb device? ;)
<jannau>
I think so, fast enough interactive keyboard / mouse usage
<jannau>
even dragging windows over the desktop is bearable but a little laggy from time to time
<bloom>
jannau: So, er, you're getting gfx mmiotraces then?
<bloom>
also, marcan: is there a convenient way to do m1n1 printfs from userspace in the hypervisor?
<bloom>
so you can do a test program `m1n1_printf("before i/o call"); some_iokit_function(); m1n1_printf("after i/o call");` and then in the mmiotrace it's obvious what to grep for
<sven>
hey, stand in line please! i asked for usb replugging first!
<bloom>
yeah do usb replugging first :-p
<sven>
:)
pugguu has quit [Ping timeout: 480 seconds]
<jannau>
sven: for which ADT nodes do you want mmiotraces?
bps has quit [Ping timeout: 480 seconds]
<sven>
usb-drd1 and atc-phy1
<sven>
maybe during plugging/unplugging some simple device
<sven>
can you also trace irqs? or is that completely left to xnu right now?
<xerpi[m]>
bloom: Something like Linux's /dev/kmsg? (and have the kernel log go to UART)
<sven>
can you still write to /dev/cu.debug-console when kprintf is enabled?
<sven>
if yes echo "hi" > dev/cu.debug-console might just work
<sven>
oh, i guess you could just disable the debug serial when launching the hypervisor and then that should definitely work
<bloom>
heh, that's a much more stupid simple way than I was imagining (using msrs as a primitive and doing an ad hoc stream protocol or something) :-p
<jannau>
I'm not fully sure if I captured the exact moment before the disconnect
<sven>
jannau: thanks! looks great already. can you maybe also plug the device in once more at the end? (i.e. to have a connect -> disconnect -> connect cycle)
<sven>
bloom: just ask if you need more stupid ideas! :P
<bloom>
-EFRIDAY
<sven>
hm, quite a few atc-phy pokes in there
<jannau>
interrupts (AIC) are out of our control
<bloom>
and you do the mmio pokey and you shake it all about
<bloom>
that's what it's all about!
<jannau>
mac os breaks rebooting via USB PD when it has access to one usb-c port
<sven>
did you re-enable the hpm nodes as well?
Method_ is now known as method_
<jannau>
yes, I removed the port 1 from setup_adt()
<sven>
i imagine that might bring the usb pd chip into a weird state