<sorear>
rqou: does retaliation refer to the siliconpr0n thing?
<rqou>
yes
<rqou>
and apparently now d!gshadow is spreading lies about it
<sorear>
What is his version of the story
<rqou>
that my release of no-symbiflow tools violated a verbal NDA
<rqou>
which is extremely false
<rqou>
it was specifically constructed not to
<gruetzkopf>
hm, a XC7A15T may be an option if i can get at the TLPs there
<rqou>
lol trying to tunnel pcie over something?
<gruetzkopf>
yes
<gruetzkopf>
this time, proper, switchable, ethernet
<gruetzkopf>
ethertype 0x22E4 :P
<rqou>
not f0f-style ethernet?
<gruetzkopf>
f0f mode would be easy to add :P
<etrig>
huh, I ordered a funny 3-in-1 programming adapter that I thought was broken but it looks like xilinx has just been shipping the wrong xusb_emb.hex ever since they released vivado I guess
<gruetzkopf>
if i do this "easy mode" i might generate ethernet frames of ~4200B though
<gruetzkopf>
if i implement a fake pcie switch i can clamp that to "normal" sizes
<rqou>
meh, within normal jumbo frame sizes
<gruetzkopf>
i should implement a fake switch anyways
<gruetzkopf>
so i can get at the SFP+ modules EEPROM and DOM
<rqou>
then it can look even more like the clusterfuck that is thunderbolt :P
<gruetzkopf>
that's the only sane part of it, really
* whitequark
stares at rqou
<whitequark>
don't even mention thunderbolt
<rqou>
we can call it etherbolt :P
<whitequark>
lol
<gruetzkopf>
i mean, i should likely expose a third device, you know, a 'normal' nic?
<rqou>
we should RE thunderbolt while we're at it :P
<gruetzkopf>
the more i read and hear about it the more i want to throttle someone at santa clara
<rqou>
not cupertino?
<gruetzkopf>
i already have enough reasons to do that
<whitequark>
lol
<azonenberg_work>
rqou, awygle: afaik RXAUI is only supported by like one broadcom chipset
<azonenberg_work>
its impossible to use for mere mortals
<rqou>
lol
<rqou>
"is a proprietary modification created by Marvell[2] and Dune Networks"
<azonenberg_work>
gruetzkopf: the xc7k160t has 8 10g gtx's
<azonenberg_work>
But fbg484 only bonds out four
<rqou>
ooh that's why i remember it was 4
<azonenberg_work>
So you need the ffg676 or larger package
<azonenberg_work>
Also prjxray is targeting kintex. So it should work
<rqou>
how big is that package, physically?
<azonenberg_work>
26 balls square 1mm pitch plus margin
<azonenberg_work>
So 27-28?
<rqou>
wait
<rqou>
so ~ 3cm x 3cm
<azonenberg_work>
Yeah
<rqou>
that seems smaller than i expected
<azonenberg_work>
And ffg. The heat spreader version
<azonenberg_work>
flip chip
<azonenberg_work>
The cheap 676 cant do 10g due to package si concerns
<rqou>
i thought they were recently requalified?
<azonenberg_work>
Only the 484 ball variant
<azonenberg_work>
FBG484 is flip chip but no heatsink and was originally specced at 6G max
<sorear>
gruetzkopf: is there something wrong with stapling together a few ecp5s?
<azonenberg_work>
They upgraded it to 10G recently
<azonenberg_work>
But apparently 676 has too long wires or something?
<rqou>
huh
<azonenberg_work>
Until then i was gonna do 1156 ball artix for the switch
<azonenberg_work>
and xaui
<awygle>
azonenberg_work: there's an NDAd Microsemi chip that does RXAUI
<awygle>
at least one
<azonenberg_work>
Now 484 kintex can do it
<azonenberg_work>
awygle: My point stands. Not accesible to mere mortals
<rqou>
can you actually get usable yield on a 1156-ball part?
<awygle>
I know
<azonenberg_work>
rqou: Never tried
<awygle>
That's exactly what I said earlier
<azonenberg_work>
It would also need an 8+ layer board. Prob 12
<azonenberg_work>
The 484 kintex is 6, maybe 8
<gruetzkopf>
i think at least for "demo" it's gonna be ECP5
<azonenberg_work>
rqou: i've toaster ovened a fbg484 kintex7 though
<gruetzkopf>
join the deep-fry club.
<gruetzkopf>
don't even really need 5G for demo purposes
<gruetzkopf>
xilinx' pcie stuff uses the normal transceivers too
<rqou>
i thought it had a hard macro?
<rqou>
idk how that is connected to things
<azonenberg_work>
its a hard mac or something
<azonenberg_work>
for pcie 2
<gruetzkopf>
it's basically impossible to find the documentation at all
<azonenberg_work>
pcie 3 wasnt final at tapeout so they use a soft core
<rqou>
lol yeah
<azonenberg_work>
You can of course softcore pcie 2 too
<rqou>
we should start by poking the phasers tbh
<azonenberg_work>
Agreed
<whitequark>
litepcie
<awygle>
litepcie uses the hard IP right?
<awygle>
and is Xilinx only?
<gruetzkopf>
"here's a list of all 7-series" "great, but i want to know exactly what i can use of this exact device at the same time"
<whitequark>
oh hm
<rqou>
need to write a "heavypcie" :P
<rqou>
or use f0f-pcie?
<whitequark>
right, it uses xilinx phys
<whitequark>
what's f0f?
<rqou>
no wait, iirc f0f-pcie was a hacked up blob
<rqou>
fail0verflow
<gruetzkopf>
it's getting worse with every single xilinx generation
<azonenberg_work>
gruetzkopf: gimme a sec
<awygle>
I'd love a "just a serdes" PCIe core, ideally in verilog but I'm not picky
<rqou>
gruetzkopf: hey, altera has a hard nios in their serdes
<rqou>
and by "branch" i mean "directory, under the branches/ hierarchy"
<whitequark>
On entry to the PE_DFP_VDM_Mode_Entry_NAKed state the Policy Engine Shall inform the Device Policy Manager of
<whitequark>
the reason for failure (NAK, BUSY, timeout or Protocol Error).
<whitequark>
god this is like walking through molasses
<whitequark>
something like 400 pages out of the 600 page specification looks autogenerated and is completely useless
<rqou>
you haven't seen anything yet
<rqou>
try a missile-chip-company datasheet
<rqou>
try 10k pages
<whitequark>
SoC datasheets being 10-20k pages is OK
<rqou>
no it isn't
<whitequark>
well other than my PC running out of memory with the pdf bitmap cache
<rqou>
one of them broke the document management/watermarking server
<whitequark>
but that's just okular being shit
<whitequark>
lol what
<rqou>
yeah
<rqou>
it was also completely useless
<rqou>
pages and pages of stuff like "mac table foobar-feature entry 0"
<rqou>
"mac table foobar-feature entry 1"
<rqou>
repeat 2^n times
<whitequark>
LOL
Bike has quit [Quit: Lost terminal]
<rqou>
i wonder how common autogenerated "documentation" is?
<rqou>
oh yeah whitequark how do you feel about hardware designed in excel? :P
<rqou>
iirc you tweeted about this before
<whitequark>
sigh
<whitequark>
not again
<whitequark>
broadcom would be the 4th major company that does this
<rqou>
amazingly, afaik they didn't
<rqou>
or at least the switches didn't
<rqou>
they had a much more... unusual workflow instead
<rqou>
but excel was only used to estimate things which seems pretty normal
<rqou>
oh yeah, they also did have the classic spreadsheet to explain to customers why the bandwidth displayed on a test set does not match expectations
<rqou>
e.g. if one clock was maximally fast and one was maximally slow then packets would be dropped
<rqou>
whitequark: this foss project is designed in libreoffice instead http://j-core.org/
<cr1901_modern>
Well, the microcode anyway
sunxi_fan has joined ##openfpga
<cr1901_modern>
"microcode editor" seems like quite a domain-specific GUI application
<rqou>
hence the use of excel :P
<rqou>
you can even use macros to generate interlocking or whatever :P
<cr1901_modern>
I feel like there should be a "microcode assembler" that's smart and autogenerates offsets for various fields in a microcode word
<whitequark>
it reads the alternate mode list through SMBus and then sets the altmode via this stupid GPIO header
<whitequark>
why the fuck they couldn't just have used SMBus for everything is beyond me
<rqou>
that's stupid
<rqou>
wait a sec
<rqou>
why does it need to loop through the cpu in the first place?
<rqou>
why can't the card itself select the mode it should use?
<whitequark>
no fucking idea
<rqou>
so um... with everything just barely hidden, why hasn't anybody just fully reverse engineered thunderbolt yet?
<whitequark>
because it's a goddamn piece of shit
<whitequark>
AAAAAAAA
<whitequark>
I figured out why it doesn't work
<rqou>
why?
<whitequark>
ACPI doesn't deliver a "USB C device is plugged in" notification
<rqou>
wait why is acpi involved?
<rqou>
i thought xhci could do that by itself?
<whitequark>
no
<whitequark>
it's for altmodes
<whitequark>
altmodes don't involve XHCI at all
<rqou>
wtf
<rqou>
why are altmodes even considered usb?
<whitequark>
they're USB because they use the USB connector
<whitequark>
you don't actually need to do anything with the USB data pairs
<rqou>
this is retarded
<rqou>
so if i just built a mechanical adapter between an sfp cage and usb-c, do i now have my own new altmode?
<whitequark>
no
<whitequark>
you need to do something with the USB PD control channel
<whitequark>
to declare an altmode
<rqou>
this hairball is ridiculous
<rqou>
why does everything depend on everything?
<whitequark>
you have to list your VID in the response to the Discover SVIDs command
<whitequark>
and then you need to list your altmodes in response to the Discover Modes command
<whitequark>
and then you need to handle the Enter Mode command
<whitequark>
and a bunch of other shit too
<rqou>
so what was your original problem?
<rqou>
why doesn't acpi send a notification correctly?
<whitequark>
who the fuck knows
<rqou>
so what's supposed to happen if it does?
<whitequark>
linux discovers the cable plug and lists it in sysfs under the usb port
<whitequark>
then it discovers the device on the other end of the cable and lists it in sysfs under the cable plug
<whitequark>
then it discovers the altmodes and lists them in sysfs under the device
<whitequark>
then you can probably poke it
<rqou>
so it sounds like you somehow forced it?
<whitequark>
except half of this is unimplemented and the other half doesn't work
<whitequark>
forced what?
<whitequark>
it doesn't work yet
<rqou>
oh nvm
<whitequark>
hm
<whitequark>
why does it say "USB power delivery version 2"
<whitequark>
in sysfs
<rqou>
isn't the "signals superimposed on vbus" the old version?
<rqou>
pre type-c?
<whitequark>
oh
<whitequark>
PD 3.0 has Revision: 3.0 and Version: 1.2
<whitequark>
there's no version 2
<whitequark>
hang on
<whitequark>
usb_power_delivery_revision
<whitequark>
2
<whitequark>
ok hm
<rqou>
if you see any mention of "shorted the data lines for 500mA" afaik that's the super duper ancient PD spec
<whitequark>
>USB Power Delivery Rev. 2.0, v1.3 and USB Power Delivery Rev 3.0, v1.1 are functionally the same except with regard to new features incorporated into USB PD Rev. 3.0 in support of USB Authentication and other forthcoming specifications.
<whitequark>
christ
<whitequark>
I hate all of this
<rqou>
oh sorry i was wrong
<rqou>
the thing i was describing is not "power delivery"
<rqou>
it's the "usb battery charging" spec :P
<whitequark>
yeah
<rqou>
oh wait
<whitequark>
ok PD 2.0 is pretty much the same wrt modes
<rqou>
you can totally signal both
<rqou>
what happens if you signal PD _and_ battery charging?
<whitequark>
dunno
<whitequark>
don't care
<rqou>
how does anybody actually test this?
<gruetzkopf>
they don't seem to do that at all
<gruetzkopf>
they don't seem to do that
<rqou>
i bet a full test of everything USB would require quite a few time capsules too :P
<rqou>
TI calculators and early PDAs did a lot of weird shit
Hamilton has joined ##openfpga
<whitequark>
lol I crashed the USB PD chip in my laptop
<rqou>
wtf
<rqou>
why can this crash?
<whitequark>
[845718.513440] ucsi_acpi USBC000:00: PPM NOT RESPONDING
* whitequark
shrugs
<whitequark>
or maybe the EC
<whitequark>
ok so if I reload the module, it correctly discovers the uh
<whitequark>
the fact that there's a partner plugged into the port
<gruetzkopf>
why is there no proper notification for that
<whitequark>
there is
<whitequark>
it's done via ACPI
<whitequark>
and it's kinda broken
<whitequark>
it does work but only sometimes
<gruetzkopf>
all this half-implemented-in-acpi stuff is terrifying
<rqou>
how possible is it to write a TB driver stack that just tears down all ACPI handlers and takes over the chip directly?
azonenberg_work has quit [Ping timeout: 272 seconds]
<whitequark>
impossible
<whitequark>
you have to talk to the USB PD chip via EC
<whitequark>
and the only interface description of EC is in ACPI
<rqou>
can't you do that via in and out opcodes?
<whitequark>
no
<rqou>
not standardized?
<whitequark>
talking to EC involves an SMM trap
<whitequark>
at least on this laptop
<rqou>
wtf
<gruetzkopf>
that's likely 100% machine specific
<whitequark>
that too
<whitequark>
every interface that's actually standardized relies on ACPI
<whitequark>
and ACPI converts the standard interface into awful shitty gunk that goes into the EC mailbox
<rqou>
gruetzkopf: you like crazy hacks, want to try it?
<gruetzkopf>
don't have any TB hosts :P
<whitequark>
rqou: uh
<whitequark>
this is literally what it is
<rqou>
does the backplane have anything special?
<whitequark>
no
<whitequark>
it just routes one PCIe connector to the other
<rqou>
how do you know?
<whitequark>
and has a bunch of misc junk like a switcher and a thermal sensor and a fan
<rqou>
that's what i would assume
<whitequark>
because I have that backplane.
<rqou>
ah ok
<rqou>
can you post a photo?
<rqou>
i can't seem to find any on the intertubes
<whitequark>
it's really not interesting
<rqou>
wait, so what incompatibility are you experiencing right now?
<whitequark>
and I'm lazy and don't wanna unscrew it
<whitequark>
uh
<whitequark>
the Apple Thunderbolt 3 to 2 adapter doesn't work
<whitequark>
I have the Thunderbolt 2 version of the Sonnet bo
<whitequark>
box
<rqou>
ah ok
<whitequark>
the card isn't available locally
<rqou>
want me to just mail you one? :P
<rqou>
i can get it with prime shipping here
<whitequark>
if you buy it for me, sure :p
<rqou>
pay me back in unusual russian electronics or something? :P
<whitequark>
uh sure, which do you want
<rqou>
idk, i can wait until later for that :P
<rqou>
so i definitely don't need the chassis, right?
<whitequark>
i'm pretty sure you don't need the chassis
<rqou>
i can just splice some of the cursed cables together? :P
<whitequark>
sigh ok let me take another look at the backplane
<whitequark>
i should wake up my roommate and tell him to take a photo of it
<whitequark>
he has one of those cameras that weigh like 2x more than my laptop and can use it really well
<whitequark>
see the thunderbolt adapter PCB photo
<gruetzkopf>
$mysterious_roommate strikes again
<whitequark>
different roommate
<whitequark>
this apartment kind of has a lot of randos in it
<whitequark>
including me lol
<rqou>
is this the apartment that got nitrated?
<rqou>
actually whitequark want to just trade for the tb2 card?
<whitequark>
yes
<whitequark>
hm
<rqou>
since that doesn't seem to be available standalone
<whitequark>
sure, if you're fine with only sending it when the tb3 one arrives
<whitequark>
on the off chance i get the adapter to work
<rqou>
sure
<whitequark>
i'm not actually sure that the tb3 card will fare any better, too
<whitequark>
i *think* it *might* work better
<whitequark>
but after looking at this horrorfest i am not sure in *anything* when it is involved
<gruetzkopf>
i believe "all" that's required to get the apple tb3->tb2 adapter to work for DP displays is to implement DP alt mode and a mechanical switch..
<whitequark>
i think so
<whitequark>
you have the firmware
<gruetzkopf>
and no reason to do it ;)
<whitequark>
i... suppose you could tactically drill the case to get at the testpoints to reflash it
<whitequark>
with a CNC mill
<whitequark>
and some pogo pins
<gruetzkopf>
did you see anything scary-usb-cc-fw-update-related in it?
<whitequark>
i haven't tried to RE the firmware yet
<whitequark>
i only confirmed that it has thumb code
<whitequark>
not compressed or encrypted
<whitequark>
no idea why the string table is mangled, it's weird
<whitequark>
it could be that my setup for reading the firmware is shit, i'll capture a trace with my LA later
<whitequark>
oh for fuck's sake
<whitequark>
the altmode support in linux is just not implemented for ucsi
<whitequark>
on top of the firmware bug that prevents hotplug notifications from appearing
<whitequark>
sigh, let's add it
* azonenberg_work
continues to suggest that whitequark simply drop the cursed protocol that is USB
<azonenberg_work>
and move to something sane like ethernet
<rqou>
huh startech now has an x520 clone
<whitequark>
azonenberg_work: you can't run an eGPU over ethernet
<rqou>
azonenberg_work: how are you planning to get the ethernet into a fruit computer?
<azonenberg_work>
rqou: i also wouldn't buy a fruit computer :p
<whitequark>
rqou: i don't use fruit computers
<rqou>
also the startech x520 clone is way more expensive than a NOS x520
<rqou>
that's pretty unusual for them; usually their pricing is pretty decent
<rqou>
oh wow the 82599ES chip is _old_
<rqou>
launched in 2009, 65nm
<gruetzkopf>
Expected Discontinuance Q1'23
<rqou>
still a super reliable chip unlike the mellanox piece of shit
<azonenberg_work>
(sure, you need an fpga or something on the far side to bridge back but...)
<rqou>
azonenberg_work: build it first
<rqou>
then talk
<rqou>
:P
<azonenberg_work>
rqou: if you gave me a pcie master
<azonenberg_work>
i could make you eGPU over RS232 if i wanted to :p
<rqou>
no
<rqou>
bad
<rqou>
should not copy f0f
<azonenberg_work>
22e4 framing over PPP over RS232
<azonenberg_work>
:p
<whitequark>
azonenberg_work: well i don't understand pcie
<whitequark>
or high speed serdes
<whitequark>
so it's easier to fix this usb-c shit
<whitequark>
the linux source defines the macro ARRAY_SIZE 47 (forty seven) times
Hamilton2 has joined ##openfpga
Hamilton2 has quit [Read error: Connection reset by peer]
Hamilton2 has joined ##openfpga
<whitequark>
ugh I hate C
Hamilton has quit [Ping timeout: 246 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
Hamilton2 has quit [Quit: Leaving]
<whitequark>
ugh do I have to download a linux source tree
<whitequark>
i ain't got disk space for that
<gruetzkopf>
wow, you're even more disk-constrained than i am
<gruetzkopf>
(looks at 4 linux trees in ~)
<whitequark>
gruetzkopf: it's mostly taken by gigantic LLVM debug builds
<whitequark>
and Windows VMs
[X-Scale] has joined ##openfpga
X-Scale has quit [Ping timeout: 245 seconds]
[X-Scale] is now known as X-Scale
q3k1 is now known as q3k
<whitequark>
rqou: ugh
<whitequark>
so the adapter advertises some mode with SVID 8087 (Intel I guess. why not 8086?) and some mode with SVID 05ac (Apple)
<whitequark>
and it looks like the 8087 mode is just "USB"
<whitequark>
what's the fucking point but whatever
<whitequark>
so the adapter *is* apple-locked
<gruetzkopf>
idiots
<gruetzkopf>
so a capture of a "normal" tb3 alt-mode exchange would help now?
<whitequark>
yes
<whitequark>
would help a lot
<gruetzkopf>
(i'd be far to easy if there was a way to query the host-supported alt modes, you know, for actually helping the user if stuff doesn't work)
<gruetzkopf>
("you've plugged in x into y1, but that only works in ports z1 to z4")
<whitequark>
gruetzkopf: uh there is such a way
<whitequark>
i just wrote a patch for linux that makes it possible
<whitequark>
it was exposed via ACPI but not actually used in linux before
<whitequark>
[856816.978580] ucsi_acpi USBC000:00: con1: found port altmode 8087:00000001
<whitequark>
[856816.978606] ucsi_acpi USBC000:00: con1: found port altmode ff01:00001c46
<whitequark>
[856817.282308] ucsi_acpi USBC000:00: con1: in altmode index 0
<whitequark>
[856817.128092] ucsi_acpi USBC000:00: con1: found port altmode 413c:00000001
<whitequark>
[856818.277557] ucsi_acpi USBC000:00: con1: found partner altmode 8087:00000001
<gruetzkopf>
a TI document i found suggests 8087:0001 is thunderbolt
<gruetzkopf>
from googling around there's deliberate incompatibility between the -2 and the -3
<whitequark>
wtf
<whitequark>
gruetzkopf: but how does it *happen*
<gruetzkopf>
i've not seen a 2-2, neither a 3-3 handshake
<whitequark>
hm
<gruetzkopf>
i'll go hunting for the -3 tooling some more
rohitksingh has quit [Quit: Leaving.]
m4ssi has quit [Remote host closed the connection]
<cr1901_modern>
whitequark: At this point in the Thunderbolt saga, I've forgotten what you were originally trying to do :P. Is the idea your adapter doesn't work, and it's b/c Apple is deliberately locking out non-Apple products?
rohitksingh has joined ##openfpga
<gruetzkopf>
the apple adapter does not work on a dell xps 13
<gruetzkopf>
and apparently there's no good reason for it
<gruetzkopf>
terrible question: have you tried this with up-to-date NT?
rohitksingh has quit [Quit: Leaving.]
kuldeep has quit [Ping timeout: 272 seconds]
azonenberg_work has quit [Ping timeout: 272 seconds]
kuldeep has joined ##openfpga
azonenberg_work has joined ##openfpga
rohitksingh has joined ##openfpga
<whitequark>
gruetzkopf: what do you think about setting "TBT emarker override"?
<whitequark>
NT, no
<whitequark>
I should
<whitequark>
actually, scratch that
<whitequark>
there's no way to control the PD controller via software on Dell platforms
<whitequark>
I've seen Dell people say that on LKML
<gruetzkopf>
that's terrible
<whitequark>
yeah
<whitequark>
the USB C ACPI interface is shitty even by already low USB C standards
<gruetzkopf>
(even this ooold dell laptop has fun ec bugs
<gruetzkopf>
sometimes keys get soft-stuck
<gruetzkopf>
also hard lockout between keyboard and trackpad
<whitequark>
gruetzkopf: wait
<whitequark>
TBTModeDataTXSOP Upper 16 bits of data to be sent on Intel VID SVDM Discover Modes (SOP) response (UFP) or
<whitequark>
used to drive TBT AM policy (DFP).
mumptai has joined ##openfpga
<whitequark>
this makes it send SVDM response 8087:00010001
<whitequark>
instead of the proper 8087:00000001
<whitequark>
the host PD still reports 8087:00000001, probably because it's buggy or something
<gruetzkopf>
can you verify that on the wire?
<whitequark>
yes, I did
<whitequark>
8087:00010001 is what it sends on the wire
<whitequark>
that surprised me
<gruetzkopf>
iinteresting
rohitksingh has quit [Quit: Leaving.]
<whitequark>
lemme add a write-reg function
<gruetzkopf>
which bit do you suspect to mean that
<esden>
tnt: ok it turns out my memory failed me once again. It turns out I have never ordered the V0.2 of the icebreaker-tiny hardware. I am working on some changes to the icebreaker to get it to V1.0, I will place an order for the icebreaker-tiny as soon as that is done so that it gains the improvements from my full size icebreaker work if there are any.