ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
yuyichao has joined #asahi-dev
yuyichao has quit [Quit: Konversation terminated!]
yuyichao has joined #asahi-dev
yuyichao has quit []
yuyichao has joined #asahi-dev
grange_c2 has joined #asahi-dev
maz_ has joined #asahi-dev
maz has quit [Ping timeout: 480 seconds]
grange_c has quit [Ping timeout: 480 seconds]
grange_c2 is now known as grange_c
phiologe has quit [Ping timeout: 480 seconds]
kov has quit [Quit: Coyote finally caught me]
flying_sausages has quit [Ping timeout: 480 seconds]
flying_sausages has joined #asahi-dev
<marcan> robher_: by the way, do you want to review strictly everything that touches devicetree/bindings, or are you okay with me pushing trivial ones to asahi-soc directly? (thinking of patches that just add SoC/board compatibles and nothing else)
<marcan> (you'll still get CCed of course, just wondering if you want me to wait for your r-b on those trivial ones or not)
<marcan> elif 'maxItems' in schema and not 'minItems' in schema:
<marcan> schema['minItems'] = schema['maxItems']
<marcan> elif 'minItems' in schema and not 'maxItems' in schema:
<marcan> schema['maxItems'] = schema['minItems']
<marcan> well that took a while to figure out why maxItems: 1 was getting added...
maz_ is now known as maz
<marcan> PMGR v3 going out now
<marcan> sven: I swear USB is just terribad on macos, even recent versions
<sven> :D
<marcan> my iMac just decided to not detect my keyboard, and I don't think any device mode shenanigans were involved here
<marcan> hope with your reset hack all this works properly on Linux :D
<sven> i'm pretty sure the ports also very occasionally break when they're in host mode
<marcan> heh
<sven> i just don't know how to provoke that yet
<marcan> yeah for me it just happens randomly
<sven> while i can reproduce the device mode fail reliably now
<sven> as much as i hate the reset hack i'm kinda convinced it's just necessary for this cursed controller at this point
<marcan> yeah
<kode54> I had to reboot recently due to USB
<sven> sleep should also fix
<kode54> it stopped detecting my USB microphone and camera, and the onboard audio stopped working too
<sven> that's when macOS triggers the dwc3 reset in the atc phy
<sven> huh, onboard audio sounds like something unrelated breaking as well
<kode54> probably needed a coreaudio reset too
<kode54> I kick that one occasionally with `sudo launchctl kickstart -kp system/com.apple.audio.coreaudiod`
<marcan> all this macos bugginess is great, we can point it out to all the "Linux will never work as well as macOS" people :p
<kode54> which I learned from how homebrew kicks it when removing plugins
<kode54> indeed
<marcan> btw, the extra 2 ports on the iMac don't work; it detects the PCIe host controller but then it dies
<marcan> will poke around
<marcan> jannau: other than that (which isn't your fault), your DTs seem to work on at least j274, j313 and j456
<marcan> I'll ack them, just want to poke around this USB issue a bit first
<_jannau_> could it be related to the cd321x? i.e. missing configuration as host only port
<marcan> no, it's the xHCI controller dying badly
<marcan> I suspect it's a problem with interrupt delivery
<marcan> looks like at least *one* irq does get delivered...
<marcan> heh, now it went into an IRQ storm
<marcan> I sense an issue...
<marcan> ah, this HC is an ASMedia, not a Fresco, so that might explain some differences
<maz> marcan: using MSI or INTx?
<marcan> MSI
<maz> some controllers have 'interesting' implementations either way...
<marcan> this controller already has quirks in xhci-pci, so...
<maz> try booting with pci=nomsi, just to see...
<marcan> nope, still fails the same way
<maz> at least it is consistent.
<marcan> yeah, heh
<marcan> well, it's been years since I had to fight xHCI... I guess it was about time it reared its ugly head again.
<marcan> dinner first, though
<maz> I gave up on xHCI after the Renesas debacle...
<marcan> which one?
<maz> uPD72020x
<marcan> what did they do? (besides have a secret handshake for their windows driver...)
<maz> goes into a very funky state if you program it with a 64bit address and then switch it back to 32bit.
<marcan> (I wrote the original version of the QEMU virtual xHCI...)
<marcan> hah.
<maz> it keeps the top bits in some intermediate, non SW visible register, and you start getting page fault in the IOMMU.
<maz> no amount of resetting can fix it.
<maz> the only solution I found was to let the fault happen, and then to reset it. only then you can get a sane state.
kov has joined #asahi-dev
the_lanetly_052___ has joined #asahi-dev
kettenis has quit [Quit: leaving]
kettenis has joined #asahi-dev
skipwich has quit [Remote host closed the connection]
aleasto has joined #asahi-dev
skipwich has joined #asahi-dev
<marcan> ouch :/
yuyichao has quit [Quit: Konversation terminated!]
yuyichao has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi-dev
pg12 has quit [Ping timeout: 480 seconds]
pg12 has joined #asahi-dev
psykose has quit [Remote host closed the connection]
<marcan> maz: tl;dr the goddamn thing has RAM firmware, embedded in Apple's *global XHCI driver* of all places
<marcan> no wonder it didn't process commands with no firmware
<marcan> events work though!
amw has quit [Ping timeout: 480 seconds]
<kettenis> gotta save those 2 cents for an EEPROM!
<marcan> nah, I think they do this because they don't like ROMs because they are places you can hide a backdoor
<marcan> they want as much stuff securebooted as possible, and firmware inside macOS implicitly is
<marcan> flash ROMs, I mean
<marcan> the firmware load procedure involves writing the memory address to a PCI config register, then writing 16 bits of data from firmware offset 0 and the top 16 bits coming from firmware offset 8000, to a BAR.
<marcan> yes, really.
<sven> lol
<sven> and the usb curse strikes again!
<marcan> I think I'm going to put this on the back burner and revisit it when I get to wifi, which also involves firmware nonsense...
<marcan> and that'll involve writing firmware extractors into the installer
<maz> marcan: it's the bestest. just burn it.
<ar> marcan: the return of the fwcutter
<marcan> I already found out I have to do that for AVD M3 firmware so...
<marcan> but whatever, who cares if we have to load some firmwares out of the recovery dmg and some out of the kernelcache in the installer >_>
<marcan> ah, I see why they used this one instead of the fresco, because this one actually does proper TypeC/Gen2/10G
<marcan> apparently this likely *is* a 3142, because the 3142 and the 2142... have the same PCI ID. lovely.
<kettenis> some of the google results suggested it is just a firmware upgrade ;)
<marcan> yeah, quite likely
<marcan> I'll buy a random 3142 PCIe card so I can validate how to tell whether the firmware is loaded or not, and that I don't break the Flash-ful ones
the_lanetly_052__ has joined #asahi-dev
<marcan> arrives today, I love Japan shipping ;)
<kettenis> would be interesting to see if Apple uses a custom firmware on not
<marcan> there's a RAM readback command, so that should be easy to check
the_lanetly_052___ has quit [Ping timeout: 480 seconds]
squags has quit [Ping timeout: 480 seconds]
squags has joined #asahi-dev
squags has quit [Ping timeout: 480 seconds]
squags has joined #asahi-dev
X-Scale` has joined #asahi-dev
X-Scale has quit [Ping timeout: 480 seconds]
pg12 has quit [Ping timeout: 480 seconds]
pg12 has joined #asahi-dev
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
<sven> okay, Rtkit command 0xb very likely is “set AP power state”. If you send it with the same state twice rtkit will crash with a message along the lines of “Invalid AP power state”
<sven> I guess that makes 0x6 “set iop power state” then
<sven> and 0x7 is the ack for 0x6 and ofc 0xb is the ack for 0xb because who needs consistency anyway
X-Scale has joined #asahi-dev
X-Scale` has quit [Ping timeout: 480 seconds]
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
yuyichao_ has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
klaus has quit [Quit: Lost terminal]
palmer_ has joined #asahi-dev
palmer_ has quit [Remote host closed the connection]
palmer_ has joined #asahi-dev
palmer_ has quit [Remote host closed the connection]
palmer_ has joined #asahi-dev
palmer_ has quit [Remote host closed the connection]
squags_ has joined #asahi-dev
squags has quit [Ping timeout: 480 seconds]
___nick___ has quit [Ping timeout: 480 seconds]
klaus has joined #asahi-dev
yuyichao has joined #asahi-dev
aleasto has quit [Quit: Konversation terminated!]
yuyichao_ has quit [Ping timeout: 480 seconds]