s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
emeb has joined ##openfpga
Jybz has joined ##openfpga
Jybz has quit [Ping timeout: 272 seconds]
dh73 has joined ##openfpga
Jybz has joined ##openfpga
m_w has joined ##openfpga
<ZipCPU>
juri_: Welcome to the channel. We're (mostly) friends here. ;P
<q3k>
right, juri_, as a soon ex-coworker of mine you should meet ZipCPU, an ex-coworker of mine!
<q3k>
some people collect stamps, i collect ex-coworkers
<ZipCPU>
Lol
<ZipCPU>
Well, I did say (mostly) ... :D
<juri_>
We've met.
<juri_>
A lot, actually. small world, indeed!
* ZipCPU
looks for that Disney song ...
Jybz has quit [Excess Flood]
Jybz has joined ##openfpga
s_frit has quit [Ping timeout: 268 seconds]
m_w has quit [Quit: leaving]
<azonenberg>
whitequark: so in today's episode of cursed USB-IF tech
<azonenberg>
(unsure if actually usb-if compliant)
<azonenberg>
You can buy usb-C cables that only have the 480 Mbps usb 2.0 data pairs in them
<azonenberg>
and are incapable of super speed operation
<azonenberg>
what's interesting is that some of them actually have the usb logo on them and are presumably usb-if certified meaning such a nightmare cable is officially OK?
<azonenberg>
(amazonbasics doesnt strike me as the sort of brand that would make outright knockoff/trademark violation products)
<whitequark>
yes, these are officially OK
<whitequark>
all USB-C cables with SS pairs actually have to be e-marked via PD
<azonenberg>
oh?
<whitequark>
which is (a) insane (b) something I suspect no one complies with
<whitequark>
sorry, let me separate things a bit here
<azonenberg>
the more i learn about usb the more i realize how much of a dumpster fire it is
<whitequark>
working off the spec open right now, I see that it permits the following cables:
<whitequark>
(a) standard C-C cables; one with all wires populated (so four SS pairs), and another with only 2.0 wires populated
<whitequark>
these are non-legacy, so actual current standard
<azonenberg>
That is awful. So by physically picking up a cable you have no easy way to tell if it's SS capable or not?
<whitequark>
these are populated in the obvious way
<azonenberg>
C-3A is legacy now?
<whitequark>
and are considered deprecated but you can still make them
<whitequark>
yes, it is legacy now
<azonenberg>
so are they trying to move host side connectors to C only moving forward?
<azonenberg>
and kill off the A connector?
<whitequark>
yes
<whitequark>
they are doign this because A does not have USB-PD
<whitequark>
and USB-PD is required for things like high-current chargers
<azonenberg>
Great. In five years we'll have laptops with eight usb-c ports, one of which can only be used as power input
<azonenberg>
one can be either displayport output or usb
<whitequark>
we are already there
<whitequark>
so, by picking up a cable you can't tell if it'll work for 2 or 2/3
<whitequark>
worse, there is Thunderbolt
<azonenberg>
I'm aware. My $dayjob laptop has two usb-c ports right next to each other
<whitequark>
and Thunderbolt requires special magic cables, and normal 2/3 ones won't work
<whitequark>
even though they have all those pairs
<azonenberg>
one is displayport output, one is power input
<whitequark>
this includes passive Thunderbolt cables with no redrivers
<azonenberg>
unsure if either/both are also normal usb data capable
<whitequark>
they are e-marked using a chip in the plug to basically say "we used less shitty coax than normal and it is no longer than 0.5 m"
<azonenberg>
i have plugged my charger into the display cable multiple times by feel and wondered why i wasn't charging
<tnt>
Isn't there some requirement that the cable as some external marking if it's SS enabled ?
<whitequark>
well sort of
<whitequark>
there's some tiny inscrutable symbol
<azonenberg>
the display connector*
<whitequark>
there's like a dozen of tiny inscrutable symbols for every purpose and it does not help
<azonenberg>
literally every single fact i learn about USB makes me more and more happy i've standardized on ethernet as the primary i/o interface for my projects
<azonenberg>
like, sure the 802.3 full spec is thousands of pages. But that includes all of the line coding details going back to thicknet
<azonenberg>
With appropriate bridging ALL of that stuff can still talk
<whitequark>
there is also VirtualLink, which uses the USB-C connector but is gratuituously incompatile with literally everything other than VirtualLink devices, i.e. special GPUs
<whitequark>
because they added a redriver on the USB 2 pairs because they wanted to push 2x8K and it did not fit into the normal SS pairs or something along those lines
<azonenberg>
...
<whitequark>
so it uses captive cables and requires a specific host
<whitequark>
it's completely fucking pointless to use a USB-C altmode for it
<azonenberg>
meanwhile any ethernet device ever made with an RJ45 port can link up with any other
<whitequark>
they actually have it configured in a way that it has USB SS but not USB HS running on it, meaning it can't even enumerate on a normal host
<whitequark>
so you need a special host AND a special one-off transaction translator
<azonenberg>
and negotiate the highest mutually supported speed over the same cabling
<whitequark>
because they got rid of transaction translators in USB 3
<whitequark>
USB 2 and USB 3 lead this bizarre parallel existence where you need USB 2 basically for the pullup
<whitequark>
for the most part
<whitequark>
but you actually have completely inependent USB 2 and USB 3 hubs in a hub for example
<azonenberg>
IMO that was another stupid design decision, not allowing usb 2.x hardware to be connected to a hub with SS-only uplinks on it
<azonenberg>
s.t. multiple 480 Mbps devices can share a common 5 Gbps uplink
<whitequark>
anyway, the AR/VR headsets actually needed what you are talking about
<whitequark>
so they got some taiwanese vendor to make them an ASIC for that
<azonenberg>
if i have an ethernet switch with a bunch of 10 Mbps devices hooked up to them, and a 1G uplink
<azonenberg>
It works as expected
<whitequark>
which isn't USB-compliant but they are *technically* compliant with USB-C spec because... drumroll... they are using a captive cable
<azonenberg>
...
<whitequark>
which means you can skip all the parts of the spec you don't like
<whitequark>
don't get me started on USB 4
<whitequark>
like usual, it's one step forward, two steps back
<azonenberg>
every time i think usb can't get worse, it does
<whitequark>
yes, they removed most of the batshit insanity in Thunderbolt, and piled up a bunch of the new one that just about compensates for it
<whitequark>
oh and of course it uses a totally incompatible line coding to Thunderbolt, so you have hubs that do Thunerbolt AND USB4 for the exact same task
<whitequark>
(they can both embed PCIe, but USB4 can also embed USB, and potentially other things)
<whitequark>
(not Ethernet though)
<whitequark>
the USB4 spec actually has empty space carved out for secret Thunderbolt registers they won't tell you what they do
<whitequark>
(the reason using a captive cable is fine is because you can't unplug it, and the cable can not turn on its buffers until you negotiate with a special PD transaction)
<whitequark>
azonenberg: fun fact: USB PD is actually very similar to Ethernet in some ways
<whitequark>
yes, the power delivery part, which is actually mandatory and is used for critical applications that have nothing to do with power delivery
<whitequark>
Thunderbolt requires USB PD for example, even though many Thunderbolt hosts will absolutely not deliver power to you
<whitequark>
regarding laptops with 8 USB C ports
<azonenberg>
8 *distinct, incompatible* usb c ports
<azonenberg>
is where i see us heading
<whitequark>
the thing is that if you have Thunderbolt or high-res DP, it's just really costly to route all that high speed shit to every single port
<whitequark>
no one other than Apple ever did 4 identical ports
<whitequark>
doing it for power is ~doable
<azonenberg>
each one with its own unique subset of AFs
<whitequark>
but doing it for 4K/8K DP and TBT is not very manageable
<azonenberg>
if you at least have the display capable one physically separate from the rest or something that makes sooome sense
<whitequark>
you'd have to build a huge tree of muxes
<implr>
lenovo (at least on the thinkpads i've seen) does power + 3 SS on all ports, but TB/DP on only one
<azonenberg>
although i would have just used a different connector key
<azonenberg>
implr: the p52s i have only charges from one of the two usbc ports
<azonenberg>
and only does displayport on the other
<whitequark>
azonenberg: fun fact: Intel does not permit vendors to make their own TBT3 peripherals
<whitequark>
you HAVE to use one of Intel's reference designs EXACTLY or they will sue you
<azonenberg>
(also see pm)
<azonenberg>
lolwut
<whitequark>
you can lay it out yourself I think, before submitting it for certification
<whitequark>
that's why... well... all TBT3 devices look the ame. it's because they're the same three or four circuits
<implr>
azonenberg: huh, interesting - t480 (and i think i've seen the same on somebodys t490) does *mark* one port as 'insert charger here', but the other one works as well
<whitequark>
you can attach different shit to PCIe
<azonenberg>
is tbt that fragile that nobody else can build it right?
<azonenberg>
implr: i have had my laptop not charge
<azonenberg>
because i plugged the thing into the video port by accident
<mwk>
implr: same on t580
<whitequark>
well it looks like Intel does not trust anyone else to build it
<azonenberg>
on my p52s
<whitequark>
USB4 is less bad, they cleaned up the worst parts
<whitequark>
it's still kind of really really bad on the absolute scale though
<whitequark>
so about USB PD
<whitequark>
do you know about USB PD 1?
<mwk>
oh gods, here goes...
<implr>
oh btw re: pd: recently I received a product from aliexpress which also included a wall charger with an A socket and a A-C cable, charger claims do 5,9,15V
<implr>
is that pd over A illegal?
<whitequark>
USB PD 1 worked by communicating over vbus using 4b5b and then FSK modulation at 23.2 MHz
<whitequark>
implr: well, the CC wire has to go *somewhere*. are there extra pins in the A connector?
<whitequark>
azonenberg: the protocol that goes over their, uh, vbus radio (that frequency isn't even legal for civilian use in RU, I think if you did, you would get a black van pretty quickly after you) is actually quite similar to Ethernet
<azonenberg>
lol
<whitequark>
so for USB PD 2 do you know what they did? they hacked off the baseband and attached it to the CC pin instead
<implr>
whitequark: yeah I just realized too that this cable makes no sense, i'll investigate once i get home
<whitequark>
they kept 4b5b and CSMA/CD, but now have a 12 point compliance eye diagram forsome insane reason
<whitequark>
note that this is for 300 kbps bit rate. that's k.
<whitequark>
it has so much overhead that they have realized that when the devices have to do a "fast role swap" (itself a very cursed concept), that won't work and they had to add another signaling scheme just for that, with less overhead
<whitequark>
so, fast role swap.
<azonenberg>
...
<whitequark>
imagine a Thunderbolt chain made from your laptop, your external display, and an USB PD charger, in this direction
<whitequark>
you unplug the USB PD charger. now the display has to switch from being powered by the charger and passing through that power to the laptop, to being powered by the laptop
<whitequark>
this is called "fast role swap" and there can be basically an unbounded amount of devices who have to compute a new power delivery policy and activate it before their capacitors dicharge
<whitequark>
which is slow enough that they can't properly negotiate via normal PD packets and use this custom scheme
<azonenberg>
wait a minute
<mwk>
wait what
<azonenberg>
in the architecture you proposed
<azonenberg>
the laptop is powered BY the display???
<whitequark>
*through*
<whitequark>
but yes, you could say that
<azonenberg>
i mean the connector is passing video data one way and power the other
<whitequark>
I think modern Apple hardware actually implements that
<whitequark>
yes
<azonenberg>
...
<whitequark>
oh yeah
<whitequark>
the data and power direction are totally independent
<whitequark>
worse, there is by design no way to control the power direction
<whitequark>
well
<whitequark>
ok, not quite
<whitequark>
they didn't explicitly require the devices to make power direction user controllable
<whitequark>
so no one did it
<whitequark>
the devices negotiate it the same way hermaphroditic snails mate
<whitequark>
the one that manages to inseminate the other first is the father
<whitequark>
i.e. the one that insists it wants to charge the other more strongly gets to be the charger, if both are dual role
<whitequark>
it is a common problem that you plug your nintendo switch in your macbook and the macbook charges from the switch
<whitequark>
google it, lots of people complain
* azonenberg
imagines plugging a laptop into a power bank and not being able to predict which is charging which
<azonenberg>
because having a separate power-in and power-out port is soooo hard
<whitequark>
yes, this is actually what you get
<whitequark>
there is a standardized way to control USB PD controllers via I2C
<whitequark>
but exposing it to the OS on PC for example is explicitly unsafe
<whitequark>
some [major PC vendor] people told me that had I found a way to do it, they would consider it a security bug
<whitequark>
so you actually *cannot* control it even with a kernel driver
<azonenberg>
...
<azonenberg>
wtf
<whitequark>
it's hooked to the EC, and the whole thing works by gluing together increasingly horrifying ACPI and SMM code
<whitequark>
because of course it still has to talk to the OS, for the alternate modes to work
<whitequark>
the OS needs to know when to send DP packets and via which connector
<whitequark>
so there's the ACPI hooks that let it know how to talk to EC
<whitequark>
but they didn't expose controlling the power direction via that at all
<whitequark>
(and of course you talk to EC via an SMM trap)
<whitequark>
fun fact
<whitequark>
a while ago, Apple banned some perfectly fine TBT3 peripherals by adding a blacklist in the kernel driver
<whitequark>
I dug in; it was because those TBT3 peripherals implemented only USB PD 2
<whitequark>
and a newer spec from Intel had it in certification requirements that TBT3 hosts had to require USB PD 3
<whitequark>
now, the USB PD controller has firmware. couldn't they have just upgraded it?
<azonenberg>
is pd3 incompatible by phy with pd2 or something?
<whitequark>
well, it turns out the USB PD 3 firmware is so enormous, they did a DIE RESPIN of the most popular controller mandated by Intel (!) to GIVE IT MORE SRAM
<azonenberg>
....
<whitequark>
they are actively hiding that fact I assume out of shame
<azonenberg>
also does this mean intel can change the spec ex post facto and make existing hardware not work with existing hosts?
<whitequark>
but it's been mentioned on TI E2E forums
<whitequark>
I think it went from 80 kB SRAM to 120 kB
<whitequark>
the reason it needs so goddamn much SRAM is because it doesn't have XIP because it supports hooking up a single flash to two USB PD controlers and a TBT controller as a cost reduction mechanism
<whitequark>
re spec: apparently so
* azonenberg
pokes head out from behind a bank of SFP+ cages, staring blankly off into space
<azonenberg>
Is it over yet?
<whitequark>
I think I'm done
<azonenberg>
Lol
<whitequark>
this is really just an overview
<azonenberg>
well now that i'm scarred for life... :p
<whitequark>
it kinda goes on in slightly less horrifying ways the more you dig in
<whitequark>
I'm pretty sure no one actually implements the PD state machine correctly
<whitequark>
and, look
<whitequark>
PD chargers can output 20 V into a C connector
<whitequark>
and there are C-µB cables
<whitequark>
so if the charger's state machine hangs...
<whitequark>
boom
<azonenberg>
meanwhile the most horrifying thing i can think of in ethernet is the dumbness that is 100baseTX's line code, with the 4b5b and scrambler in the wrong order so pathological data patterns can make you lose CDR
<whitequark>
they took zero steps to mitigate this. I don't think it's even acknowledged anywhere in the spec as a valid concern?
<whitequark>
consider that updating the firmware in the cable plug is now a thing
<whitequark>
and that each plug can have its own firmware
<whitequark>
(most will have only one controller that pretends to be in both plugs at the same time)
<whitequark>
I think the reason they allow having individual controllers in each cable plug is to do things like let them control active redrivers without adding extra wires
<kc8apf>
I use the display powering laptop via usb-c all the time. Becoming fairly common.
<kc8apf>
Universal Serial Bus: only universal because we keep calling totally different protocols the same name
<gruetzkopf>
whitequark: i noticed something in my old screenshots today
<kc8apf>
TBT3 using type C was all about Apple not ending up in a FireWire situation again
<gruetzkopf>
which matches the four link speeds given by the usb4 spec
<kc8apf>
TBT in general is Intel wanting to not lose control like they did with USB
<gruetzkopf>
note that that screenshot is from 2018
<whitequark>
hang on
<whitequark>
TBT4
<whitequark>
yeah I'm pretty sure that's what became USB4
<gruetzkopf>
which became usb4
<whitequark>
... is this why it's called USB4, without the space?
<whitequark>
did they *literally* do s/TBT/USB/?
<gruetzkopf>
we could have guessed specifics back then
<gruetzkopf>
looks like it
<whitequark>
I want to die
<gruetzkopf>
a friend is currently poking at icelakes thunderbolt controller
<gruetzkopf>
which is rumored to soon be a usb4 controller
<gruetzkopf>
really interested if/when we'll see thirdparty USB4 controllers
<noopwafel>
I was a bit horrified when I realized that Intel's 'we're going to open the TBT spec' turned out as 'aand it's the USB4 spec'
<whitequark>
it's kind of not though?
<whitequark>
I think they reworked it fairly significantly
<gruetzkopf>
not sure if there's even a TBT3 spec
<noopwafel>
well, I wanted to see the thunderbolt one
<whitequark>
I can't be sure bc the TBT3 spec was never public and there were no leaks, but from what I gleaned from RE it differs a lot
<noopwafel>
tbt3, that is
m_w has joined ##openfpga
<gruetzkopf>
(i mean, no one outside intel ever implemented TBT3)
<whitequark>
they could have an internal spec
<sorear>
I'm struggling to understand how it could work *at all ever* without an internal spec
<implr>
whitequark: sufficiently new android phones actually have a switch for consume power/provide power
<whitequark>
yup, makes sense they'd implement this first on android, where you don't have to cope with the insane ACPI interface
<whitequark>
there's no actual *technical* issue with it
<whitequark>
it's like one i2c write
<sorear>
realizing I have no real idea how hardware description works there
<sorear>
fdt is, on paper, exactly the hardware description system I want to use everywhere, but nobody who works on fdt cares about the quality of their work and it shoes
Laksen has joined ##openfpga
Laksen has quit [Quit: Leaving]
emily has quit [Quit: Updating details, brb]
emily has joined ##openfpga
<whitequark>
q3k: (were you in #glasgow at some point before or do I misremember?)
edbordin has joined ##openfpga
<edbordin>
omnitechnomancer you wouldn't happen to have been using the nick "OmniMancer" in here previously would you? I saw a bunch of chat logs talking about the Anlogic bitstreams and I'm keen to learn what people have found so far / get involved