<sven>
looks like apple has an "instance" property in their ADT on the atcphy which is either 0 or 1 on t8103 and which, among other things, decides which fuses to use to tweak some registers
the_lanetly_052 has joined #asahi-dev
<kettenis>
but you can just have the node for the atphy reference the right nvmem cells isn't it?
<sven>
yup
<sven>
nvmem cells already support bits = <start len>; so we can just have a single cell referencing the same fuse multiple times
<sven>
and afaict that's even enough to support t6000 with the same code
<sven>
erm.. *multiple cells referencing the same fuse
<sven>
just with a different mask essentially
Nspace has quit []
bisko has quit [Read error: Connection reset by peer]
Nspace has joined #asahi-dev
bisko has joined #asahi-dev
akemin_dayo has joined #asahi-dev
c10l4 has joined #asahi-dev
c10l4 is now known as c10l
kloenk has quit [Remote host closed the connection]
kloenk has joined #asahi-dev
tanty has quit []
tanty has joined #asahi-dev
eragon has joined #asahi-dev
<sven>
urgh.. one of the t8103 phys needs a slightly different fuse sequence with two more fuse values while all the others (i.e. the other t8103 and all four t6000) need the same sequence :/
<marcan>
sven: check for the extra fuses and decide that way?
<sven>
oh... true. that should work
<marcan>
do we know what the fuses do? (reg names for these?)
<sven>
the names are a bit weird sometimes, but they all seem to be related to clocks / PLLs
bisko has quit [Read error: Connection reset by peer]
<marcan>
ah
<marcan>
I wonder why the extra fuses...
bisko has joined #asahi-dev
<marcan>
anyway, we probably shouldn't have too high hopes of cross-compat for these phys, and robher doesn't really like having millions of generic DT names, so for this one it might make sense to just call it apple,t8103-atcphy
<marcan>
and the t6000 one could be apple,t6000-atcphy, apple,t8103-atcphy
<marcan>
since in this case it is compatible
<marcan>
(we do know they move the fuses around, so it's good we have the whole nvmem mechanism for that)
<sven>
still need to map the names to the actual registers but it seems to first set one value, then setup another value, and finally updates the first value again
<marcan>
ah
<sven>
while the others only need to set that first value ones. or something like that.
<sven>
it's still just rough notes here :D
<marcan>
heh, fair
<j`ey>
sven: which t8103 needs more fuses?
<sven>
the registers for t8103 and t6000 are actually the same, the target values just come from different offsets inside that fuse region
<sven>
possibly because t6000 has four sets instead of two now
<sven>
j`ey: atc-phy1 i tihnk
<sven>
*think
<marcan>
apple moved the fuses around for pcie too, I think the fusemap isn't stable
<sven>
yeah
<sven>
makes sense
<kettenis>
without the phy driver, the ports still work as usb2 ports, so it isn't a complete disaster
<marcan>
yeah
<sven>
i guess you checked that pcie really only has a single fuseset?
<robher>
phys are pretty tied to process nodes and therefore change in almost every soc.
<j`ey>
sven: ohh, I misunderstood that as one of the t8103 models (aka air, pro, mini etc), not one of the mulitple phys in the t8103
<marcan>
I'm not expecting all this stuff to magically work on future SoCs; I'm mostly betting on being able to get to the point where linux-asahi is today (except audio)
<sven>
j`ey: yeah, it's always atc-phy1 on all t8103 models
<marcan>
which has enough stuff for a distro install to go smoothly, and then you can upgrade to some HwE kernel
<marcan>
sven: the pcie fuses are global for all of APCIe, not per-port
<sjg1>
kettenis: Re the boot scripts, if you have time to review the bootstd stuff, it would help
<marcan>
I expect there will be separate fuses for the two storage APCIe instances, but ANS2 deals with that
<sven>
ok. just double checking because corellium also pretends that atcphy only has a single set of fuses fwiw
<marcan>
>corellium
<sven>
yes. the original pcie bringup was based on that
<kettenis>
sjg1: I guess I really should try that series on my machines
<sven>
that's why i'm asking.
<marcan>
yeah
<kettenis>
sjg1: but marcan and jannau here have some fearious plans to use the bootscripts to pair u-boot to a specific ESP
<marcan>
but nah, the pokes are into global PHY regs
<marcan>
not per-port regs
<marcan>
and there's a single APCIe instance
<sven>
ok :)
<marcan>
this also fits the silicon
<marcan>
APCIe is one block, with multiple SERDESes
<marcan>
while each ATCPHY is a separate block
<sven>
I guess there will be a second set for the thunderbolt pcie controller then
<marcan>
of fuses?
<sven>
yup
<marcan>
there shouldn't be, that has no PHY
<marcan>
it should all be behind ATCPHY
<marcan>
it's not a PCIe PHY
<sven>
well... the ADT has the fuses region as an entry in the thunderbolt pcie nodes
<marcan>
umm
<sven>
could be wrong since the ADT often is ofc
<marcan>
it could be there's separate fuses for thunderbolt per se
<marcan>
but it should be completely unrelated to the normal PCIe PHY fuses
<sven>
could be. something to figure out once someone gets into the mess that will be thunderbolt
<marcan>
or it could just be dummy too, if they share code with normal apcie
<marcan>
sven: wait I don't see the fuses entry in apciec0
<marcan>
I see it in atc
<marcan>
and apcie
<sven>
huh
<marcan>
not apciec
<sven>
ahhh....
<marcan>
so that makes sense
<sven>
it's in my 11.x ADT but apparently was removed in 12.x
<marcan>
ha
<marcan>
so probably garbage copypasta from apcie then
<sven>
yeah
<_jannau_>
kettenis, sjg1: we have no constraints adding a preferred boot partition UUID to bootstd either. I'm hoping adding it to bootstd will be less hacky than with the boot scripts
<marcan>
I'm guessing for apciec we can reuse the same driver, just have a different compatible since we probably need to skip some low level code
<marcan>
but the higher level interface should be similar
<sven>
yeah, the more scary part is the rest required for thunderbolt :D
<marcan>
yeah...
<marcan>
well, get USB3 working first, that's a start :p
<marcan>
also DisplayPort would be nice :>
<sven>
DP may just start to work "by accident" if that other DCP just works . XNU always applies USB3 tunables for one "lane" and DP tunables for the other
<sven>
but let's see what happens
royal1 has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
<marcan>
sven: there's a DP mux too
<marcan>
the DCPs aren't mapped 1:1 to ATCs
<sven>
ah, true
<marcan>
(pro has 2:4, max has 4:4 but still muxed)
<marcan>
there's also this cute little "stream codec" input to the mux
<sven>
is that part of ATC or a separate node?
<marcan>
which is, apparently, what they call prores0 (and only prores0! not 1!)
<marcan>
it's a separate node
<kettenis>
marcan is that "stream codec" audio?
<marcan>
prores is video
<marcan>
so apparently prores0 has the ability to, somehow, bypass DCP and stream directly to displayport
<marcan>
let's just say I have some idea what sekrit apple project that might be related to...
<sven>
hm. oh well. let me get usb3 up first then and someone else can care about DP if it's not very obvious afterwards :D
<sven>
sounds like something that could be used for DRM as well if prores can also do decryption
<marcan>
prores doesn't really make any sense as a DRMed codec though
<sven>
ok
* sven
is just guessing without any context here :)
<kettenis>
marcan: I looked a bit closer at the wifi firmware stuff for OpenBSD
<kettenis>
one issue with the current tar file is that it uses symlinks
<marcan>
sven: I mean, you know, low latency high quality codec bypassing the display pipe? what would you need such tight latency for?
<kettenis>
the OpenBSD kernel does deliberately not follow symlinks when loading firmware
<sven>
oh.. some VR/AR stuff?
<kettenis>
the other issue is that the brcm subdirectory doesn't match what we currently do for the broadcom wifi firmware
<marcan>
I mean the internet can't stop talking about apple's VR project lately so... :p
<marcan>
kettenis: the manifest can be used to copy stuff around if symlinks won't work
<kettenis>
one thought I had was to have the Asahi Installer repackage the firmware into an OpenBSD-compatible firmware package
<kettenis>
I think the manifest contains enough information to do that
<kettenis>
(and obviously I would contribute that code)
the_lanetly_052__ has joined #asahi-dev
yuyichao has joined #asahi-dev
the_lanetly_052 has quit [Ping timeout: 480 seconds]
<marcan>
kettenis: it would be a bit tricky because we'd either always have to have multiple formats (wasteful) or we'd need different "generic UEFI" options, one for Linux variants and one for OpenBSD variants
<marcan>
ideally I'd prefer it if we settle on some standard, and then the OS itself does whatever transform it needs to do to put it into its preferred structure
<marcan>
is it hard to do that transform once OpenBSD loads the tarball? I figured you could just untar it, rename the directory or whatever, and resolve symlinks
<kettenis>
discussing some options with Theo
<kettenis>
currently looking at selectively extracting files from the archive such that we can use them early on in the installer
<kettenis>
but that is where the symlinks complicate things
<kettenis>
I see why you chose symlinks; it makes things more explicit
<kettenis>
but would using hard links instead work for what you have in mind?
<marcan>
hm, in a tarball?
<marcan>
I guess that's a thing, need to check to see how to make that from python
<marcan>
linux won't care either way
<kettenis>
yes, I think you use LNKTYPE instead of SYMTYPE
<tpw_rules>
yeah, that's exactly how you do it
<marcan>
sure, why not
<marcan>
kettenis: feel free to test it and send a PR if it works for you
<kettenis>
will do
royal1 has quit [Ping timeout: 480 seconds]
<sven>
marcan: so... chances are I can already blindly support this T8112 phy as well :D
<sven>
looks like the fuses are essentially the same again and just the "port reset" maybe works a bit different
<sven>
... or maybe this can't do a port reset anymore? but either way, it mostly uses t8103 functions except for essentially those two
<sven>
ah, t6000 actually already doesn't have that port reset thing anymore apparently. so, uh, t8112 phy is more or less the same i guess
<alyssa>
sven: sounds like you're having fun
<sven>
just enjoying myself until the usb curse will inevitably strike again while writing this driver! ;)
<alyssa>
it hasn't yet?
<sven>
not yet
<sven>
But usb3 also isn’t working yet so there’s plenty of time
<bluetail[m]>
is it possible to create a live-stick so that we can test if we should? I have a odd setup of 7 usb disks which are fed by a active hub and going into one usb 3 port.
<sven>
it’ll be a few more weeks before there’s something to test
<alyssa>
sven: hf
<bluetail[m]>
to anybody already running AsahiLinux: Is there power management? Does it always run on 100%? How is the power consumption? I know, no concerns in early stages, but I'm curious if there is such finding which requires us to build a new cpu governor.
<j`ey>
bluetail[m]: #asahi is the channel for questions like that
<bluetail[m]>
ok. I will repeat there.
MajorBiscuit has quit [Ping timeout: 480 seconds]
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
thebigbossch[m] has joined #asahi-dev
<kettenis>
cool, the last patch for t6000 support is now in u-boot master as well
<kettenis>
I rebased the u-boot asahi branch once more even though it doesn't really make a difference