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
klaus has quit [Ping timeout: 240 seconds]
raster has quit [Quit: Gettin' stinky!]
DarkShadow44 has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
DarkShadow44 has joined #asahi
bgianf has quit [Remote host closed the connection]
ephe_meral1 has quit [Ping timeout: 246 seconds]
klaus has joined #asahi
klaus has quit [Ping timeout: 252 seconds]
odmir has quit [Remote host closed the connection]
<method_>
Hey marcan, since you're online and sent a message recently I felt its a good time to ask, Is it alright if I use a bot that relays message to / from discord I wrote, I keep it private to myself of course
<method_>
Just asking because I use discord a lot more than irc, and forget to check my client often
<marcan>
if it's private it's ok
<marcan>
that's just a funny bouncer
<method_>
Yeah pretty much, it makes it much easier for me to interact
<method_>
I'm actually quite proud of it, I wrote it from scratch myself ^.^
<method_>
First time I've tackled such a project
VinDuv has joined #asahi
klaus has joined #asahi
vlixa has quit [Remote host closed the connection]
jeffmiw_ has joined #asahi
jeffmiw_ has quit [Client Quit]
Chainsaw has joined #asahi
<marcan>
ok, USB is done and hooked up to the proxy, and I made Linux boot work properly with it, shutting down and such
<marcan>
(so the host doesn't see a dead USB device)
<marcan>
sven: ^^
<marcan>
so you can now do linux.py --tty /dev/<some uart> with M1N1DEVICE=/dev/ttyACM0 (the m1n1 ACM device)
<marcan>
it's all still backwards compatible with ancient versions. I want to see how long I can get away with my old installed m1n1 that doesn't even support the MMU :)
<marcan>
(well, it's not actually backwards compatible at the protocol level, but proxy.py tries the new way before falling back to the old way)
<sven>
very nice :-)
<marcan>
fixed some fail in USB too (it wasn't actually kicking tx/rx properly, same issue we had with the UART in linux)
<marcan>
and applied for a proper PID for us
<sven>
yeah, i at least know two or three parts in my usb code that weren't exactly compliant to the spec
<marcan>
fixed some spec issues too, yeah
<sven>
:-)
<marcan>
there are still unimplemented requests but I added a few
<sven>
yeah, i just did the minimum required to get it to work on mac os and linux
<sven>
luckily they are used to horrible usb devices ;)
<marcan>
lol
<marcan>
you had the endpoint constant defines backwards btw :p
<marcan>
0x80 is IN
<sven>
ouch :D
<sven>
it worked though, didn't it? :P
<marcan>
yes, for bulk, because there are both anyway
<marcan>
I was very confused about the interrupt endpoint which you claimed was OUT :p
<sven>
lol
<marcan>
but then showed up as IN
<marcan>
I initialize the interrupt EP now, otherwise the host keeps retrying
<marcan>
I never send anything, it just needs to be there and NAK
<marcan>
(not stall)
<marcan>
and same with bulk in, you were sending ZLPs all the time which spams the bus
<marcan>
uh, are you using --tty with the same device as M1N1DEVICE?
<sven>
no :)
<marcan>
did you boot with debug enabled? :p
<sven>
something's weird, let me try to figure out what's going on
<sven>
ah, duh. wrong /dev node
<sven>
it's /dev/cu.debug-console
vimal has quit [Ping timeout: 260 seconds]
maknho____ has quit [Ping timeout: 252 seconds]
maknho____ has joined #asahi
<sven>
marcan: you forgot to run make format, there's a spurious whiteline in main.c now :P
<marcan>
whaaa
<marcan>
*force pushes*
<marcan>
nobody saw anything
<sven>
riiight :P
<sven>
now i wonder how iboot detects usb reconnects then
raster has joined #asahi
<marcan>
sven: reconnects work fine for me
<marcan>
:-)
<sven>
really?
<marcan>
yup
<sven>
thats's... weird
<sven>
they don't work for me
<marcan>
wait, what happens when you try?
<sven>
nothing
<sven>
the usb device doesn't show up again
<sven>
and i never see any USBRst or USBConnected events
<marcan>
HA
<marcan>
yeah okay
<marcan>
repro'd
<marcan>
the problem isn't dwc, it's the TI chip
<marcan>
*dwc* handles reconnects fine
<sven>
yeah, that's what i figured
<sven>
i can manually force a reconnect on the dwc side
<marcan>
but my cable breaks out only D+/D- to the USB end
<marcan>
so "reconnect" for me means only the USB link, not VBUS
<sven>
ohhhh
<marcan>
I bet I know what this is; I bet the TI chip does not bring up the DFU mode by default
<marcan>
sec
<sven>
this also happens when i bring up the phy in host mode
<sven>
and then use linux's xhci driver
<sven>
the first connection to a port works
<sven>
but nothing afterwards
<marcan>
actually, not sure, something about my vdm stuff is broken right now
<marcan>
not getting replies
totebagel has quit [Quit: Leaving]
<marcan>
ok, it's not the pin mapping; doing it doesn't fix it
vlixa has joined #asahi
<sven>
yeah, it's something strange
<sven>
even bringing up the TI chip with that special apple command doesn't help
<sven>
it does enable the PD negotiation stuff though
<sven>
my best bet still is that it somehow relies on interrupts from the TI chip :/
<sven>
which we could poll as well but ugh...
Bublik_ has quit [Ping timeout: 252 seconds]
Bublik_ has joined #asahi
ephe_meral1 has joined #asahi
<marcan>
sven: I wonder if there is a VBUS pin going to the dwc?
<sven>
i've looked at the whole dwc register space using RegMonitor and I didn't see any interesting bits flip when connecting a usb cable
<sven>
i didn't look at the atc-phy space though
<kettenis>
just pushed a rebase of the pcie branch
<sven>
hrm. wait. maybe i just found a bit that's flipped
<sven>
it's not part of the known dwc3 range though i think
<marcan>
sven: in iphone schematics at least, there is a VBUS_DETECT pin on the soc
<sven>
0x502200024 starts at 0xa2000042, then goes to 0xa1000042 after i connect the cable and then finally to 0xa0000042 when i disconnect the cable again
<sven>
but it just stays there then if i connect it again
<marcan>
sven: does it work again if you re-init the phy and such?
<sven>
marcan: i mean.. it works if i just manually force the dwc3 part to reinit the device even without touching the phy
<marcan>
huh
<sven>
yeah
<sven>
it's weird
<marcan>
*something* has to change then
<sven>
yup
<sven>
just not sure what that it yet
<kettenis>
addressed sven's comments on the pce pull request
<kettenis>
so that might be ready to be merged
<sven>
lgtm :)
<kettenis>
been thinking a bit about the pcie dt-bindings
<kettenis>
apcie is somewhat unique in that is a RC with three integrated ports
odmir has joined #asahi
<kettenis>
amost all other pcie RCs that Linux supports in DT mode have only a single port
<kettenis>
so that raises the question where to put properties like reset-gpios and max-link-speed
<marcan>
I thought the three instances were largely unique; what's shared?
Chainsaw has quit [Remote host closed the connection]
<kettenis>
config space!
<kettenis>
(and I'm talking about the RC that has the onboard devices, not the Thunderbolt stuff)
<arnd>
kettenis: are you sure we actually need these properties? Do you ever need to configure the link speed or trigger a reset using gpio?
<kettenis>
We (or at least u-boot) needs the reset gpios
<kettenis>
my current understanding is that max-link-speed isn't strictly necessary
<kettenis>
would be merely an optimization to not try the higher link speeds on peripherals that don't support them
<kettenis>
it seems the SoC supports pci gen4, but the peripherals are gen3 (wifi) gen2 (xhci) and gen1 (ethernet)
<kettenis>
it also seems that the SoC supports clkreq (no surprise for what's essentially a phone SoC)
<kettenis>
but the refclk-always-on-2 property in the corellium tree suggests that clkreq may not be supported for the ethernet device
<arnd>
Is the link speed set through standard pcie registers, or a hardware specific phy driver?
<arnd>
my hope was that this would all be part of what m1n1 can do before u-boot does the bus scan
<kettenis>
looks like it is special glue logic like on most/all dwc pcie controllers
<kettenis>
corellium has some code dealing with the link speed that uses a max-speed-2 property
<arnd>
a lot of the server chips actually use dw-pcie implementations, but all the phy handling is done in firmware before it gets handed off to the OS
<kettenis>
bringing up the links could be moved in m1n1, but then you'd lose the ability to turn them off for suspend
<kettenis>
that's something most server SoCs don't worry about...
<kettenis>
if we can express all this using proprties from the standard pci-bus binding I don't see why we shouldn't
<arnd>
right
<arnd>
which implies using the dw-pcie driver plus some hardware glue, right?
<kettenis>
if my reading of the pci-bus.yaml schema is correct it is allowed to have reset-gpios and max-link-speed on pci-pci bridge nodes
<kettenis>
not sure if using the dw-pcie driver code in linux makes a lot of sense as there is very little actual logic that you'd be able to re-use
<kettenis>
but I guess that's up to whoever is going to write the linux driver
<arnd>
that makes sense, since you can have nested buses. I think part of the problem is the the DT bindings for PCI largely go back to the pre-pcie days where a lot of things worked differently, and that the dw-pcie hardware in particular only normally implements a single port rather than a root complex
<arnd>
It might be helpful to look at what the older Marvell PCIe driver does, since that emulates a root complex with multiple ports on top of hardware that is somewhat similar to the separate dw-pcie ports
<arnd>
so I think the the mvebu pcie binding reflects the root complex that does not actually exist in hardware
<arnd>
But since it seems that Apple actually implemented a proper root complex with multiple ports, we wouldn't need to emulate one here, just adjust the Linux driver to properly deal with multiple ports
<kettenis>
right; the example I found of a RC with actual ports is the "old" tegra20 one
<kettenis>
that is an example of how it could be done
<kettenis>
needs some msi-related properties added to it, but maz already had a suggestion for that
<kettenis>
the "pci@2,0" node will be needed anyway to add the child device node for the ethernet controller such that we can stick the "local-mac-address" property there
<arnd>
right, it seems that the binding is not actually the problem here, it's more a question of how to convince the linux dw-pcie driver to handle it correctly
<arnd>
kettenis: is the u-boot driver for dw-pcie derived from the Linux driver?
<kettenis>
not as far as I can tell
<kettenis>
currently there are seperate standalone drivers for all the dwc variants u-boot supports
<kettenis>
I've seen a patch series to unify them in some way
<kettenis>
but even then I think you end up with 90% of the code being overrides
<arnd>
that might actually help here. In the Linux driver, the common code for dw-pcie makes the assumption that port==root_complex==host_bridge, unlike the tegra driver you found and the mvebu driver that fakes a root complex
<arnd>
Not sure how much this needs to be reworked, but if we need to introduce the concept of actual ports, the dw_pcie 'struct pcie_port' probably needs to be split into the port specific bits and those that are shared for the root complex
<arnd>
or possibly just renamed if it turns out that everything in there is common to all ports
<arnd>
There is already a 'struct dw_pcie' that is looks like it should represent the root complex, but it contains a single 'struct pcie_port', along with members that should be port specific (num_lanes, link_gen, ...), while the 'struct pcie_port' seems to only have members that should be part of the root complex
<kettenis>
everything upside down
<arnd>
I suppose the current split exists in order to separate endpoint from host most
<arnd>
'dw_pcie' contains the information for both modes, while 'pcie_port' only contains the bits that are specific to host mode
<kettenis>
so as far as I can tell, Apple didn't integrate the DesignWare ATU
<kettenis>
that means almost all code in pcie-designware.c would be unused
<kettenis>
the interrupt code is also completely different
<kettenis>
and ECAM is properly implemented
<kettenis>
so most if pcie-designware-host.c is useless as well
<kettenis>
at that point you might as well pretend it isn't designware at all ;)
<arnd>
kettenis: so what is left beyond what the generic pcie host support gives us? only suspend mode, or something beyond that?
<kettenis>
and beside the msi support?
<kettenis>
there is an issue that the wifi chip needs to be powered on
<kettenis>
this done by sending commands to the SMC
<arnd>
MSI doesn't have to be done in the pci host bridge driver, I think it's usually done in there because it shares the register space, but in this case there are no registers for MSI
<kettenis>
there are registers for MSI
<kettenis>
so really that has to be handled by the host bridge driver
<arnd>
what do the registers do? I think when I read the corellium driver a while back, it didn't touch any registers for MSI, just passed everything down to the AIC
<kettenis>
host ridge registers need to be initiaized to make that happen
<arnd>
but isn't that someting that could be done in m1n1 or u-boot rather than having the OS know about it?
<kettenis>
you still have to have something that mappes an MSI vector number to an AIC vector number
<kettenis>
corellium modelled the wifi power control using some sort of emulated GPIO
<kettenis>
but it may make more sense to make it a power domain
<kettenis>
I didn't find a precedent for hardware that needs to explicitly power on a pcie device
<marcan>
arnd: will poke around nvme next btw (now that I can load kernels fast :))
<arnd>
kettenis: does the wifi device show up at all if you don't enable the power? As long as the driver can bind to the device, it can read a custom property to do whatever is necessary
<arnd>
if the power needs to be enabled first, we may have to add the equivalent of drivers/mmc/core/pwrseq.c for pci
<arnd>
kettenis: regarding the MSI mapping, I'm aware that this needs to be done somewhere, but as I said that does not involve registers, so it could be outside of the PCI host bridge driver if that ends up being easier
klaus has quit [Ping timeout: 252 seconds]
klaus has joined #asahi
choozy has joined #asahi
<kettenis>
arnd: the device doesn't show up at all if you don't power it up
artemist has joined #asahi
<arnd>
ok, I see
<kettenis>
judging from the ADT contents, the SMC is involved in power management and wakeup
<kettenis>
so maybe having the SMC manage thing indepently from pcie is an option
<arnd>
any idea if macos toggles it at runtime? if not, it's probably enough again to have u-boot turn it on before starting Linux
<arnd>
if we decide that it is needed, then a copy of Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml for PCI should work
vimal has joined #asahi
<arnd>
MMC currently has a generic "simple" power sequencing driver that handle almost all devices, plus two device specific ones for those that are not as easily abstracted
<arnd>
compliant MMC/SDIO devices shouldn't need any of those, but it's fairly common to have to kick an SDIO device in some for (clock-enable, reset, regulator, ...) before it can be probed
<arnd>
In theory, SDIO is not different from USB or PCI here, but I don't recall it being needed on these so far
<kettenis>
no clue about what osx does, but it appears to be a simple on/off toggle
<kettenis>
not sure why the corellium folks came up with code that supports somewhat more complicated power sequencing
<arnd>
it probably comes down to how much power we can save by turning it off then, compared to just doing the regular PCIe ASPM
<arnd>
if the power savings are not substantial, I'd just turn it on during boot
<arnd>
or is this possibly needed for RFKILL functionality?
<arnd>
(i.e. airplane mode)
<arnd>
In that case, I suspect it could be modeled as a platform specific rfkill device, as long as pcie hotplug works correctly to bring it back up
odmir has quit [Remote host closed the connection]
<kettenis>
right, I'll see if I can figure out what happens if I turn it on after booting OpenBSD
odmir has joined #asahi
<kettenis>
the root ports don't advertise native pcie hutplug support though
odmir has quit [Ping timeout: 240 seconds]
odmir has joined #asahi
m42uko has quit [Quit: Leaving.]
m42uko has joined #asahi
<pipcet[m]>
so I was looking for the most trivial device in my MacBook Pro's ADT, and I think I found it: I've figured out enough about the keyboard backlight PWM for it to be useful, I think; I can control it from m1n1 or Linux now, no driver code yet though
<marcan>
arnd: I don't want to waste time on PM stuff until I know that there are savings worth having
<marcan>
i.e. until I sit down with a power meter
<marcan>
pipcet[m]: nice :)
<pipcet[m]>
the built-in power metering/energy budgeting looks fairly sophisticated (plus there are all those temperature sensors), so maybe we don't need that meter...
Chainsaw has joined #asahi
maknho____ has quit [Ping timeout: 265 seconds]
maknho____ has joined #asahi
<marcan>
if we can figure it out, definitely
<marcan>
is that in-soc only, or does it include external parts?
<marcan>
I'd probably still want to cross-check with external metering just to be sure we understand it though :)
<pipcet[m]>
probably a good idea. No idea about the hardware side of it, I just saw it in the device tree (and I think it was mentioned in the Corellium code or docs somewhere...)
jeffmiw has quit [Read error: Connection reset by peer]
odmir has quit [Remote host closed the connection]