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
<marcan>
bloom: I thought of using the m1racles register for that :D (userspace hypercalls)
<marcan>
cut also yeah debug-console works I guess
<marcan>
:p
<marcan>
*but
<marcan>
though that shows up on the wrong ACM port, it's not serialized with mmiotrace
<marcan>
so the msr trap thing is probably a better idea long term
<marcan>
plus I want to also use it to control m1n1 (turn mmiotrace on/off)
<bloom>
marcan: I also thought of the miracles reg lol
<bloom>
not being serialized with mmio is a showstopped
modwizcode has quit [Remote host closed the connection]
<amw>
My shell.py connection is failing with Bad command on connection, possibly due to unable to find ADT node pci-bridge1.pcie? - see https://paste.debian.net/1200069
<amw>
I am thinking of re-installing the m1n1 on the M1 macbook, but perhaps something else needs to be updated
<Emantor[m]>
bloom: Barebox, https://www.barebox.org was initially an U-Boot fork which removed a lot of unsupported code and adheres closer to the Linux driver interfaces, making driver ports to/from the kernel much easier. It also provides a somewhat saner CLI than U-Boot, at least to my eyes.
<Emantor>
amw: do you have any error messages in the dmesg of the computer your mac is connected too? On my desktop mainboard at least one of the USB ports did not reliably work with m1n1 and I also needed a stable kernel update.
<Emantor>
amw: m1n1 is the latest build? Are you chainloading latest m1n1 beforehand? S_BADCMD looks to be raised if m1n1 doesn't know the command that the python-proxy requests.
<amw>
ok - I'm running the latest on the client / python side, but a 1-2 week old one M1 side. I'll try the chainload first
<amw>
Yes that's fixed it - python3.9 proxyclient/chainload.py build/m1n1.macho - I can now run shell.py!
<pipcet[m]>
Emantor: barebox looks really cool, thanks for sharing the link. What did you have to change?
<Emantor>
Nothing much, I hacked in DBEUG_LL support, but adjusted the S3C Uart driver now, so it works as well. It's really not much code, I'll see if I can get USBGadget up and running, than I can simply chainload from m1n1.
<pipcet[m]>
Emantor: I meant the configuration as well (I only just heard about barebox). If you want to share that, that would be great :-)
<jannau>
amw: sound like a regression of making checksums optional. I'm not sure if we care as long as chainloading a newer m1n1 works
<amw>
jannau: Yep - I added a note to the Developer Quick Start to help any others in the future. I'm fine with that
<alessandrorzz[m]>
Hi, someone can help me with an issue in arch Linux?
<Emantor>
pipcet[m]: Do you have a 1.2V Uart on the debug port? Otherwise barebox isn't really usable on m1 yet.
<Emantor>
jannau: I think m1n1 on his computer was missing the get/set_SIMD command, so the proxy complained, I don't think this has to do with the checksums.
<amw>
I do have a vague memory that I may have run it with the checksums so I suspect Emantor is right.
<pipcet[m]>
Emantor: no, but just getting it to chain-load would be nice. I understand it doesn't have the drivers yet.
<jannau>
yes, it is the missing P_GET_SIMD_STATE command. I should have looked at the log first
<sven>
so... can we somehow virtualize AIC to also get all interrupts in the mmiotrace? :>
<sven>
i really need to fix my setup and get that thing working *sigh*
<pipcet[m]>
do you need to virtualize it? Just mmiotrace reads from the AIC event register?
<sven>
do all interrupts go through the hv right now?
<sven>
ohhh
<sven>
duh
<pipcet[m]>
all interrupts require a read of offset + 0x2004 to know which source it was
<sven>
hm. that might be slow though
<sven>
but worth a try
<pipcet[m]>
I've done it with my abortive stolen-core pseudo-hypervisor, it seemed okay then.
<pipcet[m]>
(but I was logging to memory not USB, so...)
<sven>
jannau: ^-- wanna give that a try? :>
<sven>
i'll try to get my setup working in the meantime
<jannau>
I'll try
<jannau>
works but is quite noisy and slow. should be handled in m1n1 with the ability to ignore uninteresting event types and numbers
<sven>
yeah, that's what i expected
<sven>
the interesting ones for the usb port would be 857,858,859,860 and 816
<sven>
the 816 is especially weird there ;)
<sven>
i can hack the reconnect to work already. just need to check read32(0x502a90008) & 0x0100000 and then do set32(0x502a90004, 3); clear32(0x502a90004, 3)
<amw>
VinDuv: Sorry not sure how to handle that pull-request - I have only git clone of the repository here
<jannau>
any idea why some adt nodes have "#interrupt-cells = 2"? interrupt property looks like it is consectutive interrupts
hexchain has joined #asahi
<pipcet[m]>
the multi-touch device has something weird in the second cell, at least: 0x02000000
<jannau>
the gpio nodes have 7? consectutive irqs
pugguu has quit [Read error: Connection reset by peer]
<pipcet[m]>
... but their interrupt-parent is aic, which has #interrupt-cells = <1>
pugguu has joined #asahi
<pipcet[m]>
and, yes, the pins are mapped to one of seven IRQ groups
<jannau>
hmm, nodes which use "/arm-io/gpio" as parent have 2 cells
<pipcet[m]>
yes, the #interrupt-cells property applies to interrupt-children :-)
<jn>
the #*-cells properties usually specify how many cells should be used when the node in question is used as a resource provider for something else, i.e. when the GPIO controller is used to provide GPIO interrupts
<jn>
at least in modern linux usage, but i think this goes back to common times
<pipcet[m]>
so GPIO has seven AIC interrupts, multi-touch has a single GPIO interrupt described by two cells, the first of which is a pin number and the second presumably encoding whether it's edge triggered/level triggered/low/high, or something.
pugguu has quit [Read error: Connection reset by peer]
pugguu has joined #asahi
<jannau>
sven: I haven't found an obvious interrupt which fires at connect/disconnect. 190 from "/arm-io/gpio" is very noisy so I can't if that one is used
<sven>
you can sniff i2c traffic if you want
<sven>
that should give away if it's using the USB PD chip
<jannau>
I suspect the interrupts property for nodes which uses /arm-io/gpio as interrupt specifies gpio pin, index into /arm-io/gpio's interrupts to get the mapped AIC interrupt
<sven>
the other alternative i can think of would be to specify if the interrupt triggers on hi/low edge/level
malvo has quit [Ping timeout: 480 seconds]
<jannau>
i2c0 is very noisy as it its interrupt 627
<sven>
huh, weird. i wouldn't expect much traffic to go through the i2c chip
<sven>
and i think it's only those usb pd chips on i2c0
<jannau>
yes, according to the ADT there's only hpmBusManager on it
<sven>
strange. might make sense to write something that sniffs i2c traffic
<jannau>
have you seen a pa semi manual? mac os uses 0x18, 0x2c and 0x44 in addition to the registers in the linux driver
<sven>
no, but there's a decent change you can ignore them
<sven>
they might be related to interrupts
<sven>
i doubt they matter to sniff the traffic though
<Emantor>
0x44 is weird, always set 1 during the write and reset directly afterwards. From my i2c traces 0x08 with mask 0xff00 could indicate number of received bytes.
<pipcet[m]>
uhm, they are named and documented in the corellium driver (but if you prefer guessing, that's okay, of course)
malvo has joined #asahi
<sven>
sure, i believe marcan also has a pa semi datasheet he got by asking the guy who wrote the linux driver. but either way, to sniff i2c traffic all you should need are the two fifo registers
<Emantor>
Yep, shouldn't be too hard to turn this into i2c reads/writes.
malvo has quit [Remote host closed the connection]
malvo has joined #asahi
malvo has quit [Remote host closed the connection]
malvo has joined #asahi
<jannau>
second interrupt cell is more likely flags, the second cell of the bluetooth node is 0x20_0002
kubes has joined #asahi
kubes has quit []
kubes has joined #asahi
kubes has quit []
<Emantor>
sven: I took a look at your dma question in #armlinux, and just saw now that it's been there for a while. I am off now, I can look at this some more tomorrow.
bps has quit [Ping timeout: 480 seconds]
<sven>
Emantor: thanks!
VinDuv has quit [Quit: Leaving.]
bps has joined #asahi
* bloom
should setup the hv hm.
bps has quit [Ping timeout: 480 seconds]
* bloom
reads m1n1 wiki again
<sven>
let me know if you get it work
<sven>
i always hit "panic(cpu 0 caller 0xfffffe0014c6f0f8): "ApplePMGR: virtual void ApplePMGR::initDriver(IOService *):1557 REQUIRE failed: id != kIDReserved"
<bloom>
i was hitting something stupid last time too
<sven>
yeah, i'm 99% sure this is me doing something incredibly dumb
<sven>
i just can't figure what yet
<bloom>
It would help if my linux laptop had working usb drivers.
<bloom>
do I have a spare linux machine for this? ummmmm
<brentr123[m]>
I have a spare linux machine
<brentr123[m]>
my pc has a dualboot
<bloom>
thanks.
<bloom>
erm i guess i can requisition the odroid...
<brentr123[m]>
ah but its x86
<brentr123[m]>
may not work
<bloom>
m1n1 shouldn't care
<brentr123[m]>
so what command should i do on the linux machine to help you?
<bloom>
oh, heh, I meant a spare machine for usb stuff here :)
<bloom>
I can't believe the current take away is "I don't have enough computers" ;P
<brentr123[m]>
I have like 5
<brentr123[m]>
1 mac
<brentr123[m]>
2 pcs
<bloom>
oh but does the odroid have usb-c
<bloom>
nope, ugh
<yrlf>
bloom: how much control do rooted android phpnes have over their usb c ports?
<bloom>
TTY> Recovering from exception (ELR=0xfffffe001224ef20)
<bloom>
TTY> Exception taken from GL1t
<bloom>
TTY> Running in GL2
<bloom>
^ Is this something people have seen loop (along with dumped registers) when trying to boot hv?
<bloom>
needed to rebuild + chainload m1n1
<bloom>
sven: etc
<bloom>
now i see a progress bar come up and lots of MMIO spammed at me but the display has gone black so I don't know if it's making progress
<bloom>
oh there it is
<bloom>
sven: what is pmp[17] and why is it so noisy during boot?
<sven>
i've only seen "panic(cpu 0 caller 0xfffffe0014c6f0f8): "ApplePMGR: virtual void ApplePMGR::initDriver(IOService *):1557 REQUIRE failed: id != kIDReserved" no matter what i do :(
<sven>
and no idea what pmp[17] is
<bloom>
ok it finally boot, nice
<bloom>
how do I actually.. do anything with this?
<bloom>
between how slow boot is and that this is all being fed over a serial port err
<sven>
it's also just running on one efficiency core afaik
choozy has joined #asahi
choozy has quit []
<bloom>
yeah that would help lol
<bloom>
wonder if pmp is NVMe
<bloom>
oh der no
<bloom>
PMP: "Power Management Processor?". Handles power functionality
<bloom>
thanks wiki
<bloom>
Ok, I have hypervisor macos. Cool.
<sven>
iop,ascwrap-v4
<sven>
that's pmp apparently
<sven>
don't think that's nvme
<bloom>
yeah sorry im confused
<sven>
huh. wait.
<sven>
okay, wtf apple
<sven>
why do you reuse the iop,ascwrap-v4 compatibility for so many things
<sven>
it's probably talking to some co-processor
<bloom>
yeah ok.
<bloom>
including controlling the curosr plane apparently? :p
apetresc has joined #asahi
<bloom>
ok, this is awesome
<bloom>
I can poke the display controller regs with macOS booted from hv
<bloom>
note to self: writing bad things to fb format bits can wedge the whole system, even in macos
<bloom>
expensive lesson to learn given how slow hv is to boot