ChanServ changed the topic of #asahi-re to: Asahi Linux: porting Linux to Apple Silicon macs | Hardware / boot process / firmware interface reverse engineering | WARNING: this channel (only) may contain binary reverse engineering discussion | RE policy: https://alx.sh/re (MANDATORY READ) | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-re
yamii has quit [Quit: WeeChat 3.3]
amarioguy has quit [Remote host closed the connection]
yamii has joined #asahi-re
nicolas17 has quit [Quit: Konversation terminated!]
nicolas17 has joined #asahi-re
Retr0id has joined #asahi-re
phiologe has joined #asahi-re
PhilippvK has quit [Ping timeout: 480 seconds]
jakebot has quit [Quit: The Lounge - https://thelounge.chat]
jakebot has joined #asahi-re
<rqou_> anyone got an aarch64 opcode map reference guide?
<rqou_> apparently i need to fix "HV: store not emulated: 0xad008901"
<rqou_> ... or not, apparently simd regs aren't even available in exc_info
<rqou_> hey marcan how hard would it be for you to fix this?
nicolas17 has quit [Quit: Konversation terminated!]
user982492 has joined #asahi-re
<phire> rqou_ Lina was actually working on this problem on yesterday's stream.
<rqou_> lol ok
<rqou_> i missed that
<rqou_> has the code been pushed yet?
<phire> Implemented the 256bit reads/writes, then ran into a pathological problem with reads split across pages. So not pushed
<rqou_> rip ok
<rqou_> i added a hack for just the opcodes i need for now, which seems to not crash in my case
<phire> should work if the thing you are tracing is page aligned. It only runs into issues if a read/store starts on a previous non-traced page, and overflows into the page you are tracing
Graypup_ has quit [Quit: meow]
Graypup_ has joined #asahi-re
<rqou_> afaict it's not guaranteed to be page aligned, but happens to be for now
<rqou_> yolo
<marcan> rqou_: you should read the broadcom wifi driver
<marcan> everything you're describing about the window stuff sounds exactly like what it does
<rqou_> i have been reading it, but it doesn't look the same?
<marcan> I mean the idea of remapping the BAR window via config space
<rqou_> many parts are similar though
<marcan> and I doubt they have a different PCIe core for bluetooth so it should have the same registers for that?
<marcan> also there are several BAR windows, linux only uses one AFAIR
<marcan> at least two configurable ones
<marcan> and then other hardcoded ones
<rqou_> yes, macos definitely uses more
<rqou_> for bluetooth
<marcan> yes, it uses two for wifi too
<rqou_> macos seems to use 5 for bluetooth
<rqou_> i did find that one of the config space registers matches the wifi side
<rqou_> everything else seems different though, even the layout of message rings
<rqou_> or the firmware boot process
<marcan> that's not surprising
<marcan> I would expect the PCIe core to be ~the same, but not a lot of the rest since the bluetooth stuff has a very different lineage
<rqou_> tbh poking the lower-level bar window stuff is a pain because the instant you do a "bad" read the whole system locks up
<rqou_> something about error recovery might be broken
<rqou_> in the pcie core
<marcan> I know
<marcan> it's unclear if there is a way to recover
<rqou_> but yeah, the pcie looks similar, and there's definitely a chipcommon
<marcan> since a stuck MMIO isn't exactly recoverable except by another CPU
<marcan> which is not sane
<marcan> is there really no linux driver for this at all? like no other bluetooth driver that fits? some broadcom sdhc stuff? some android source drop?
<rqou_> it can't be turned into a bus error?
<marcan> I find it hard to believe nothing else uses this
<rqou_> hrm, i'm not aware of anything
<marcan> I dunno, maybe? I mean it sounds like a TLP that never completes
<rqou_> there's broadcom uart bluetooth
<marcan> maybe there's some way to configure a timeout
<rqou_> which afaict is also different
<rqou_> i haven't done a thorough check of android vendor kernels though
<rqou_> afaict nobody has bluetooth on pcie
<rqou_> it wouldn't surprise me if broadcom cooked up something special just for apple
<Jamie[m]1> implication of this gentoo wiki article section is that some sort of broadcom pcie bluetooth is supported
<rqou_> afaict that's USB
<Jamie[m]1> oh hmm
<rqou_> i strongly suspect this is something broadcom made special for apple, out of existing IP blocks
<rqou_> if you ever meet me in person, ask me about the facetime hd chip
<rqou_> the driver class names also strongly implies something custom: AppleConvergedPCI -> AppleConvergedIPC -> AppleConvergedIPCOLYBTControl
<rqou_> this whole thing feels very apple overcomplicated
<rqou_> with an ipc mechanism over pcie where you can set up multiple pipes
<rqou_> afaict it _does_ eventually tunnel bluetooth hci though
<rqou_> after also taking a detour through a giant undocumented networking-related stack called skywalk (which i do not care about)
<marcan> that was recently (finally) dumped
<rqou_> neat
<rqou_> i don't care about skywalk though
<marcan> anyway yeah, it sounds like this is an apple-specific instantiation of broadcom bluetooth, pcie, and some glue
the_lanetly_052 has joined #asahi-re
the_lanetly_052___ has quit [Ping timeout: 480 seconds]
<rqou_> ugh what's the proper way to figure out which DART stream a pcie device is using?
<rqou_> it seems nondeterministic
<rqou_> wtf, AlignmentError on STUR emulation
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rqou_> it's really not quite designed to trace access to general RAM, isn't it
user982492 has joined #asahi-re
<rqou_> everything here is over-layered AF
<rqou_> seems there's a "main" message and completion ring, which maybe is used to "open" a pipe containing its own message and completion rings?
<rqou_> but somehow this has to share a fixed number of doorbells
<rqou_> and there's a mapping between everything encoded in the macos plist
kameks has joined #asahi-re
the_lanetly_052 has quit [Ping timeout: 480 seconds]
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
user982492 has joined #asahi-re
<rqou_> success(-ish)! i can read what appear to be bluetooth HCI commands that macos is sending to the bluetooth card
<rqou_> still don't understand replies though, nor a giant pile of magic numbers
<sven> looks for rid2sid in the Linux pcie driver to get the pcie device/dart stream mapping
<sven> it’s configurable
<rqou_> but i see a 0xFC01 command, a 0x0C13 command and my computer hostname, and then a huge pile of 0xFD97 with a payload that starts with "BLOB"
<rqou_> sven: how do i do that from a trace script though?
<rqou_> rn i hardcode it and reboot if it seems wrong
<sven> trace the writes to that rid2sid register and then find the stream from there
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Jamie[m]1> can I stop myself from being sent into recovery mode after rebooting many times in quick succession?
<Jamie[m]1> (i know i can get back into the OS by picking it from the boot picker, but trying to prevent being sent there in the first place)
<jannau> see what smc reboot does, there is a boot errror count and if that exceeds a certain value iboot boots into recovery
<jannau> I think it's sensible that it is only reset by the os but for m1n1 experimnets it would be nice to have
<jannau> would have been useful for display experiments and m1 ultra bringup
<Jamie[m]1> yeah, avd experimenting is where i'm wanting it now
<rqou_> whoops i forgot to go to bed, but success! https://github.com/AsahiLinux/m1n1/pull/192
kameks has quit [Ping timeout: 480 seconds]
kameks has joined #asahi-re
kameks has quit [Ping timeout: 480 seconds]
nicolas17 has joined #asahi-re
MajorBiscuit has joined #asahi-re
user982492 has joined #asahi-re
<roxfan> sleep is for the weak
<marcan> I actually don't get sent into recovery most of the time and I reboot all the time; I'm not sure exactly what the logic is
<marcan> (without doing the count reset)
<j`ey> never been sent into recovery either
<sven> me neither, and i've rebooted this thing a lot and very quickly
<sven> the only time I was sent into recovery was when I let that weird other watchdog thing expire
<jannau> I think reboots are fine, reboots after crashing dcp or trying to use powered down usb ports seems to cause it
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
MajorBiscuit has quit [Ping timeout: 480 seconds]
user982492 has joined #asahi-re
Mase3206 has joined #asahi-re
Mase3206 has quit [Quit: Mase3206]
Mase3206 has joined #asahi-re
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Mase3206 has quit []
Mase3206 has joined #asahi-re
MajorBiscuit has joined #asahi-re
MajorBiscuit has quit [Ping timeout: 480 seconds]
user982492 has joined #asahi-re
MajorBiscuit has joined #asahi-re
Mase3206 has left #asahi-re [#asahi-re]
alexsv has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
doggkruse has joined #asahi-re
doggkruse has quit [Ping timeout: 480 seconds]
yrlf has quit [Quit: The Lounge - https://thelounge.chat]
yrlf has joined #asahi-re
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
user982492 has joined #asahi-re
user982492 has quit []
user982492 has joined #asahi-re