lexano has quit [Remote host closed the connection]
<pie__>
anything that doesnt need a registration?
<whitequark>
rqou: when's your work time ends btw? it's 3am here
<rqou>
unfortunately i leave really late
<rqou>
like 7pm local time here
kuldeep has quit [Ping timeout: 272 seconds]
<whitequark>
oh so like in 2 hour
<rqou>
yeah, and then another hour for silly valley traffic
kuldeep has joined ##openfpga
<feuerrot>
pie__: til: it does. The other two recommendations at stackexchanges are either dead or require an account. https://markdownshare.com does work.
<pie__>
oh thanks
<pie__>
how did you find a stachexchange post? i didnt think to explicitly check stackexchange but "markdown paste" didnt yield me any useful google results
<pie__>
man, no way to set an expiration date? oh well, not too important
<feuerrot>
pie__: I used 'markdown pastebin' as the google query
<pie__>
yeah i just gave it a poke but given that the other one gives a deletion link i like that better
lexano has joined ##openfpga
<azonenberg_work>
rqou: its not intel vs amd optimization per se that is the issue
<azonenberg_work>
rqou: intel tends to have less cores but better single thread performance
<azonenberg_work>
amd tends to optimize more towards heavily multithreaded server workloads with more cores that are each less good
<azonenberg_work>
So really it depends on how parallel your code is
<rqou>
i thought there was also controversy about icc and/or Intel's math libraries doing shady things?
<azonenberg_work>
well if its an intel library
<azonenberg_work>
it will be tuned for their hardware (duh)
<azonenberg_work>
But in general, i havent seen much evidence of anything optimized for one uarch over another
<rqou>
in the past they explicitly checked cpuid for GenuineIntel and assumed the cpu didn't support anything fancy otherwise
<rqou>
e.g. not even sse
<azonenberg_work>
that may have been a vestige from before amd implemented it?
<azonenberg_work>
that they just had no incentive to remove?
<rqou>
i have no idea
<azonenberg_work>
In other news, the left side of the lab is progressing nicely
<azonenberg_work>
alpha-bravo and center walls are painted, ceiling is painted except for the charlie end
<rqou>
iirc Via explicitly had a "change cpuid" tool that would cause small but measurable performance differences
<azonenberg_work>
charlie side wall and ceiling plus the top of the little "shelf" still have to be painted
<azonenberg_work>
i'm starting to do finish electrical today
<azonenberg_work>
then started the order process for the conductive epoxy floor
<azonenberg_work>
(still waiting for them to send me the official quote)
<azonenberg_work>
The whole delta side of the lab is still bare studs but i am probably gonna try and do the sheetrock in the SAR room first
<azonenberg_work>
because that will let me hook up a lot of power
<feuerrot>
felix_: hackmd is a really nice etherpad-style service for markdown, but according to our admin it leaks memory like no other selfhosted service.
<azonenberg_work>
Once I have the floor in, i can also start installing the racks
m_w has joined ##openfpga
balrog has quit [Quit: Bye]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
<awygle>
rqou: ryzen is fine, it's honestly not that much slower on single threaded workloads. i've been very happy.
balrog has joined ##openfpga
futarisIRCcloud has joined ##openfpga
<feuerrot>
azonenberg_work: did you name your lab sides after the nato alphabet? (if yes: why?)
<azonenberg_work>
feuerrot: Yes and no
<azonenberg_work>
This is actually standard fire department terminology for naming sides of a room/building
<azonenberg_work>
alpha is the side facing the street, then go clockwise
<azonenberg_work>
Rather than saying north/south/east/west, which imply that you have a compass reference
<azonenberg_work>
the A/B/C/D sides are obvious just from visual inspection
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
<awygle>
That's a good idea and it makes me want to build a house where the second floor is rotated 45 degrees from the first.
<feuerrot>
azonenberg_work: why would N/S/E/W (especially E before W) imply compass reference? I only know the N/E/S/W-way (aka 'Nie Ohne(Osten/East) Seife Waschen' in ger)
<feuerrot>
er, 'E before S'
<azonenberg_work>
feuerrot: thats what i meant sorry
<azonenberg_work>
but saying "north side of the room" requires knowing which way north is
<azonenberg_work>
"alpha side of the room" only requires knowing where the street is
<azonenberg_work>
Which is easier if you're dropped into an unfamiliar location
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined ##openfpga
rohitksingh has quit [Client Quit]
rohitksingh has joined ##openfpga
kristianpaul has quit [Ping timeout: 252 seconds]
kristianpaul has joined ##openfpga
kristianpaul has quit [Ping timeout: 240 seconds]
[X-Scale] has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
<rqou>
whitequark: sonnet upgrade cards arrived
<rqou>
one is officially labeled "for Echo Express SE1" and the other is "for Echo Express III-D or III-R" but they look identical
<rqou>
let me know which one you want and we can arrange how to ship
* sorear
wonders how common buildings without a single obvious front are
X-Scale has quit [Ping timeout: 272 seconds]
[X-Scale] is now known as X-Scale
<azonenberg_work>
sorear: i imagine in such a case, wherever the incident commander is standing would be declared the alpha side for that fire
<rqou>
whitequark: interestingly, these boards don't have any obvious firmware flash for the TI chip
<sorear>
all of the examples I can easily come up with are subway stations
florolf_ has quit [Ping timeout: 240 seconds]
<awygle>
I feel like many large buildings take up entire blocks. My specific examples are mostly university buildings
<rqou>
uhhh
<rqou>
the FW release notes for this chip explicitly mention fixing a stack corruption
florolf has joined ##openfpga
<awygle>
I want a desktop vm host with an extra button wired into a gpio on the mobo where the hypervisor maps a vm framebuffer to the screen and switches to the next one when the button is pushed (also swapping the input devices to the displayed vm)
<awygle>
Is there a reason this is a dumb thing to picture? It seems doable
<fseidel>
you'd need serious OS patching to make it happen
<fseidel>
but I can't imagine it being impossible
rohitksingh_work has joined ##openfpga
<fseidel>
not sure why you'd need it on the mobo though
<awygle>
idk i just want a hardware switch so the keyboard acts like a normal keyboard
<fseidel>
oh, then sure
<awygle>
and i don't have to worry about accidentally hitting CTRL+ALT+WIN+7 and dropping into Super Root Mode or some nonsense
<fseidel>
easiest way would probably be to have the switch trigger an interrupt for the host
<fseidel>
and have each FB be located in physical memory somewhere, with the guest VM pagetables getting its own framebuffer
kuldeep has quit [Ping timeout: 252 seconds]
<sorear>
idk maybe use a midi footpedal for the switch?
<awygle>
that's a cool idea
<fseidel>
sorear++
<sorear>
just has to be a separate device, most OSes are terrible at multiple keyboards but you're already proposing major hypervisor hacking
<fseidel>
the OS course I took a little while ago had us hack a virtual display thing onto the kernels we had written as part of a "build a simple hypervisor project"
<fseidel>
every guest got a fake framebuffer
<awygle>
that sounds cool
* awygle
never took OSes
<fseidel>
and when you hit ctrl shift tab, the host would dump the real FB to the current guest's fake FB and switch to another guest's fake FB
<fseidel>
mapping the real one in to its pagetable and dumping the contents of its fake one (effectively a savestate of the last time it was active)
<fseidel>
any time a program running in a guest not on the display wrote to the screen, it would go to the fake guest
kuldeep has joined ##openfpga
<fseidel>
you could presumably do something like this with a real hypervisor, and if you wanted, map the swap operation to a footpedal
<fseidel>
no idea how this would behave with things like GPUs, we stayed in the realm of VGA textmode
Bike has quit [Quit: Lost terminal]
<awygle>
i seem to remember someone discussing things just falling off a PCIe bus recently
<rqou>
> someone
<rqou>
you mean all the people currently involved in whitequark's thunderbolt saga?
kuldeep has quit [Ping timeout: 240 seconds]
<rqou>
oh huh i _just_ noticed how these two tb3 cards are different
<rqou>
the brackets aren't the same
<rqou>
i was so focused on the pcb that i didn't notice
kuldeep has joined ##openfpga
oeuf has quit [Read error: Connection reset by peer]
oeuf has joined ##openfpga
<azonenberg_work>
awygle: lool i wish i had an OS class like that
<azonenberg_work>
my "operating systems" class introduced fork(2)
<azonenberg_work>
it was "basic C for POSIX" basically
<azonenberg_work>
awygle: re the framebuffer stuff
<azonenberg_work>
It probably wouldn't be that hard to add multi-client support to that fpga vnc client project i've wanted to do for a while
<azonenberg_work>
multi-serveR*
<azonenberg_work>
gah
azonenberg_work has quit [Ping timeout: 245 seconds]
<rqou>
which reminds me that i really need to make some progress on my (constantly backburner-ed) projects to build some "reproduction" cartridges with both good engineering practice, low cost, and no EOL/NRND parts
<rqou>
(seriously why do "repro" people love crap like EOL CPLDs and flash?)
<cr1901_modern>
5V
kuldeep has quit [Ping timeout: 246 seconds]
<rqou>
use buffers?
<cr1901_modern>
Takes space, easy to f*** up apparently :)
<rqou>
nah
<rqou>
use non-autosensing ones
<rqou>
works every time
<rqou>
space is fixed by using "modern" technology like SMD/BGAs
<rqou>
seriously why do large factions of "hobby/maker" electronics act like they're stuck in the 1980s/early 90s?
kuldeep has joined ##openfpga
<cr1901_modern>
Is this in part inspired by ppl ripping apart that OPL3 board I bought :P?
<cr1901_modern>
I would guess they're stuck b/c, even if they have a reflow oven, BGA == "I actually have to think/exert mental effort about how to route this PCB".
<rqou>
i have no idea what opl3 board you're talking about
<rqou>
this is literally just inspired by that "crippling nostalgia" rom hack
<awygle>
rqou: that is 90% of what i want in a pokemon game, and it seems to have been taken down since that video went up
<cr1901_modern>
see ##yamahasynths chat. But if you haven't nevermind
<rqou>
wait it has?
<cr1901_modern>
Yea Nintendo took down a shitload of pokemon hacks a few days ago
<awygle>
at least i had to get it from archive.org last night
<cr1901_modern>
or at least the tool to make them
<awygle>
man that's such a bummer. fuck off nintendo.
<rqou>
wtf this literally _just_ got taken down
<cr1901_modern>
Nintendo is very much going to send ppl back to torrents/make preservation harder. And b/c it's in their best business interest to do so.
<cr1901_modern>
They don't take things down tho unless it reaches critical mass it seems. Can't wait for them to take down the disassemblies of pokemon
<cr1901_modern>
:/
<rqou>
oh shit i forgot about that
<rqou>
should clone those preemtively
<cr1901_modern>
I have a cute workaround around that in theory; don't include the disassembly of the repo, but rather include a tool plus data that can _generate_ the disassembly
<cr1901_modern>
And perhaps a tool that can generate the tool that generates the disassembly :)
<awygle>
i feel like that's worse? at that point you're just distributing the rom lol
<rqou>
yeah i've seen people discussing how to safely do things like that
<cr1901_modern>
awygle: No, users have to provide their own ROM
<awygle>
oh
<rqou>
iirc either bunnie or marcan had an idea for a tool that would distribute only diffs of annotations
<awygle>
so you just distribute the annot - yeah that
<rqou>
with hashes to make sure everything matches up
<rqou>
i don't remember if it was just an idea or a working tool though
<rqou>
oh yeah this hack apparently isn't distributed as a .ips
<rqou>
it's a .gbc/.cia, nice for inviting banhammers
<awygle>
yup
<rqou>
how do i get archive.org to actually give me an unmangled file?
<cr1901_modern>
oh right, all the roms are on archive.org too. But it's not individual files
<rqou>
also seriously "the community" (whatever that means) really needs to invent something smarter than .ips
<cr1901_modern>
That's what byuu's beat patcher is for. Of course nobody uses it
<rqou>
yeah i don't get it
<rqou>
why do people dislike byuu?
<rqou>
oh huh archive.org seems to detect wget and feeds you a normal page with no header
<rqou>
ooohshit this is a **GBC** .cia file
<rqou>
yeah that's super illegal
<awygle>
yyyeah
<rqou>
btw out of curiosity anybody here actually know the .ips format?
<rqou>
what a trashfire
<cr1901_modern>
it's prob a text file on zophar
<cr1901_modern>
geez, there's a name nobody uses
<rqou>
yes among other places
<azonenberg_work>
(22:20:15) rqou: seriously why do large factions of "hobby/maker" electronics act like they're stuck in the 1980s/early 90s?
<azonenberg_work>
I dont know but this is why arduino, sparkfun, etc stay in business
<azonenberg_work>
people who still do 5V DIP breadboard projects because they think SMT is scary
<rqou>
except arduino _does_ have stuff in more modern design styles
<cr1901_modern>
From discussion from another channel about "why is byuu disliked?" just yesterday:
<cr1901_modern>
He doesn't things his own way, and it pisses others off that he gets stuff done in spite of this. And well, he can be difficult as a person.
<rqou>
so does sparkfun
<rqou>
btw fun thing i just re-remembered about .ips files
<rqou>
the format is so shitty it's not even good enough for expressing patches to all GBA games
<rqou>
but they got really lucky and you can express (simple) patches to pokemon
GuzTech has joined ##openfpga
<awygle>
dumb git question - how do i amend a commit so that it doesn't include a file anymore?
<rqou>
use the correct type of git reset :P
<rqou>
iirc it's `git reset --soft HEAD^`
<awygle>
do i want to do git commit --amend afterwards, or just git commit?
<marcan>
cr1901_modern: I've met byuu, he's actually a very reasonable person. but it seems he's managed to butt heads with some of the more idiotic factions of the internet, which seems to be a common theme when you do anything related to games, really
<rqou>
o/ marcan
<marcan>
I don't think that diff-disasm thing was my idea but it sounds reasonable enough
<marcan>
also, re: patch formats, why not bsdiff?
<rqou>
ok maybe it was bunnie's idea?
<marcan>
could be
<cr1901_modern>
marcan: I don't have a problem w/ byuu
<rqou>
idk why not bsdiff
<cr1901_modern>
I was just relaying a convo in another room that would know
<rqou>
the "rom hacks" scene seems to love ips
<cr1901_modern>
marcan: Also...
<cr1901_modern>
(10:17:09 PM) cr1901_modern: emulation community is about "who can most effectively wield minutate about esoteric topics as a blunt object"
<marcan>
heh
<marcan>
re: ips, I guess it works for basic hacks, but bsdiff can handle things like totally rebasing an executable, efficiently
<rqou>
yeah i know
<rqou>
classic problem with .ips when people decided to insert more rom pages in the middle
<marcan>
yeah, bsdiff will handle that
<marcan>
lol ips has a 16MB limit?
<marcan>
damn it's crappier than I thought
<rqou>
yeah
<rqou>
3-byte offsets
<rqou>
good enough for pokemon, let's ship it :P
<rqou>
(for people who don't know: the pokemon gba games were just under 16 mb; max size is 32 mb)
<cr1901_modern>
IPS is ancient news at 11
<awygle>
oh fuck it's 11
* awygle
scurries off to bed
<cr1901_modern>
Hah I went to bed at 9:30, woke up at 12:30, good morning
<marcan>
huh, they used CCD delay lines in laserdisc players, TIL
<rqou>
heh, i while back i looked into how optical drives work and they're actually quite impressive pieces of technology
<gnufan>
awygle: i've seen your link to the Lichee Tang splash with Anlogic Eagle FPGA, it's an interesting FPGA! after GoWin, this China vendors are really trying to become more popular on the Western market.. riding the RISC-V horse
<gnufan>
i've seen also they are offering that FPGA with a BG256 pinout said to be "HW compatible" with similar offering by Intel/Altera and Xilinx to retrofit directly on routed design on PCB, first time i see this approach..
<gnufan>
the board is on sale on Taobao for ~10$, i'm wondering when it will arrive on an European-ready reseller, they say Banggood.com could get them, some time in the future..
<gnufan>
anyway, i'm trying to use the SDK i found on the Telegram Lichee-pi chat (named Tang Dynasty 4.1), and i'm toying to see if the "prjTrellis" documentation steps could apply to it, too..
<gnufan>
it looks like a very educational project.. BTW on the Telegram chat, they alread talked about "yosys" support for those FPGA and one guy, supposed to be working on Anlogic tech support, said it would be interesting but in a couple of years.. funny but they looks like to be already aware of the FOSS HDL toolchain..
<whitequark>
rqou: pong
<whitequark>
just woke up
<rqou>
i got a "file" for you
<rqou>
70 mb, how should i get it to you?
<whitequark>
rqou: sec
rohitksingh_wor1 has joined ##openfpga
<whitequark>
rqou: see pm
rohitksingh_work has quit [Ping timeout: 272 seconds]
GuzTech has joined ##openfpga
<rqou>
hmm, anybody have any idea why this capable-of-being-fully-isolated el inverter deliberately connects the secondary and primary?
rohitksingh_wor1 has quit [Ping timeout: 244 seconds]
kuldeep has quit [Ping timeout: 272 seconds]
kuldeep has joined ##openfpga
s_frit has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<whitequark>
gruetzkopf: lol of course i couldn't find heads from tails in the adapter fw
<whitequark>
apple wrote their own fw based on ti reference fw
<whitequark>
it's massively changed
keesj has joined ##openfpga
<keesj>
hi
sensille has joined ##openfpga
<keesj>
I was (shortly) talking on #fpga on the topic of creating my first FPGA based hw design. I really want the minimal setup pretty much https://github.com/tinyfpga/TinyFPGA-A-Series (A1) with about 20 leds
<keesj>
I have done small HW projects before (using KiCad)
<rqou>
keesj: if you're asking "what should i do next" the usual answer is "look at a reference design/example and then decide which parts you will keep/replace"
<keesj>
yes. I will first try to get the design loaded in kicad(5) without errors and start playing around(fixing missing libraries and such) next I might need some advice on the jtag header or similar.
<tnt>
2 layer is fine. Believe me, I'm using an upduino right now to run design at 50 MHz ... and you can't possibly make a worse board than that.
<keesj>
tnt: based on UL1K?
<tnt>
Well on that board it's an UP5k
<gnufan>
keesj: UP5K-SG48 is the way to go.. if the 20 leds are a chain of WS2812B or similar smart leds! :-)
<gnufan>
..as there are pretty few IO pins..
<tnt>
Ah yeah the UL1k is not available in qfn48.
<tnt>
then yeah up5k is your best bet. And there are 39 IOs, you can easily drive 20 leds with that.
<gnufan>
..the UP5K has a core for just 3 IO pins for typical use case of RGB leds with high current.. (and PWM too for "breathing"), don't know if it can drive 20 leds on the other general IO pins
ym has quit [Quit: Leaving]
<tnt>
gnufan: depends on the led :)
<tnt>
Those are "high" power 24 mA driver.
<tnt>
I can't find any specs for the other pins mak source/sink current.
<keesj>
I don't have much fixed (this should be a learning project, have a small FPGA supported by the open toolchain) the current design calls for 20 leds (for a logo) but really anything "cool" would do (ir led, generating an AM signal,usb HID) but I want is small e.g. not as bulky as my previous project https://github.com/keesj/A10-OLinuXino-LIME-5510-Shield
<keesj>
I will readup on the different options for the chips and try to find a good application for it.
<tnt>
High efficiency leds will be plenty bright at a couple of mA current, so driving them from normal IO would be no issue at all.
<s_frit>
keesj: last i checked XO2 didn't have open source toolchain support
<tnt>
s_frit: indeed. that's why I proposed ice40 instead :) downside is you need a spi flash for the config.
<tnt>
(well ... they are OTP as well if your design is final)
<s_frit>
tnt: my upduino 2.0 arrived today. what are your criticism's of the board design?
<tnt>
I haven't looked at the 2.0, I only have the 1.0.
<keesj>
yes, xo2 is a bad idea
<sensille>
oh, is the upduino a cheap board for ice40? is there also one for the hx8k?
<tnt>
But ... basically the layout was horrible. the ground was a _trace_ going all over the board and very thin in some places. The decoupling was nowhere near where it was needed.
<s_frit>
keesj: i think the tinyfpga Bx used a BGA part, whereas the ice40UP is available in 0.5mm QFN48 package (and i think the ice40UltraPluse support was added to icestorm after tinyfpga B was designed, maybe?)
<s_frit>
keesj: yes that page. there is an upduino 1.0 and 2.0 board there
<keesj>
thats looks like a nice starting point (I will want to use KiCad) but looks good
<s_frit>
i am planning to do an ICE40UP board with KiCad too, but I have no experience with KiCad or making SMT boards, so I'd be interested to follow your progress if you make it public
<s_frit>
there is a part definition for the ICE40UP in the standard KiCad 5 install, by the way
<s_frit>
tnt: so for a 2-layer board, what would you prefer to see? bottom dedicated to ground plane?
<tnt>
It might be impossible to be completely dedicated, but yeah, it should be as filled as possible and only cut to make 'jumpers' across traces on the other side.
<marcan>
TAL: lol neural networks
<gruetzkopf>
whitequark: of course they did...
<whitequark>
gruetzkopf: I have the upstream firmware running and negotiating over USB PD.
<whitequark>
... with a VDO:0x00000001.
<whitequark>
and it still doesn't fucking work.
<whitequark>
piece of shit.
<gruetzkopf>
what the hell
<gruetzkopf>
what's it configured for?
<whitequark>
Thunderbolt, either as a legacy adapter or not
<whitequark>
I need a real Thunderbolt 3 device apparently :/ :/
<gruetzkopf>
there's that bit "force TB entry even if emark is wrong"
<whitequark>
yes, I set that too
<whitequark>
but I think it's for DFP, not UFP
<whitequark>
hm, I could try configuring SOP-Prime
<whitequark>
let's see
<whitequark>
gruetzkopf: idea.
<whitequark>
I could use their other tool to look at the registers in the firmware of the USB PD controller in my laptop.
<gruetzkopf>
assuming EC doesn't mess with the config, yes
<whitequark>
oh what
<whitequark>
this firmware is extremely old
<whitequark>
gruetzkopf: LOL
<whitequark>
I made it switch to DisplayPort
<gruetzkopf>
one thing apple can't do
<whitequark>
I don't think I actually have DisplayPort anything anyway
<gruetzkopf>
don't have too many DP displays either
<whitequark>
gruetzkopf: do you think you could serve as a second pair of eyes?
<whitequark>
I want to cross-reference everything in the PD exchange that can be modified with the firmware config
<whitequark>
gruetzkopf: oh and btw, CD3215B is TPS65983A
<whitequark>
I tried to flash it with the -B firmware (which is said to work with only -B silicon) and it didn't boot
<whitequark>
so CD3215C is TPS65983B
<gruetzkopf>
sure, though i'll hop under the shower for a moment and then be on mobile internet
kuldeep has quit [Ping timeout: 252 seconds]
kuldeep has joined ##openfpga
mumptai has joined ##openfpga
<whitequark>
gruetzkopf: ok so I'm looking at the "Disc Ident VDM"
pie___ has joined ##openfpga
<gruetzkopf>
ok, let me open the standard
pie__ has quit [Ping timeout: 246 seconds]
rohitksingh_work has quit [Ping timeout: 246 seconds]
rohitksingh_wor1 has joined ##openfpga
ym has joined ##openfpga
<gruetzkopf>
found it
rohitksingh_work has joined ##openfpga
rohitksingh_wor1 has quit [Ping timeout: 252 seconds]
rohitksingh_work has quit [Ping timeout: 272 seconds]
rohitksingh_work has joined ##openfpga
mumptai has quit [Read error: Connection reset by peer]
mumptai has joined ##openfpga
ym has quit [Quit: Leaving]
rohitksingh_work has quit [Read error: Connection reset by peer]
<cr1901_modern>
Wow, I don't think I could solder wires to that
<cr1901_modern>
Are there points on the motherboard where one can attach wires that go to the flash?
<cr1901_modern>
(I think my soldering tip is too wide and not thin enough to "get on top" of the small part of the pad that sticks out of a QFN. Too easy to cause bridges.)
<rqou>
funny because many people i know use really large tips
<rqou>
just add more flux or something
<rqou>
alternatively use hot air instead
<whitequark>
cr1901_modern: no
<whitequark>
I soldered to the edges of the pins
<whitequark>
it was ez
<whitequark>
the spacing is very large
<whitequark>
gruetzkopf: no not WSON-8
<whitequark>
it was like WSON-8 but scaled up exactly two times
<whitequark>
yeah it was a 6x5 mm WSON-8
<whitequark>
W25Q80
<gruetzkopf>
WAT
<tnt>
wson8 is already 1.27 mm (.1 inch) between pins.
<whitequark>
hm
<cr1901_modern>
I've read it's 0.65mm from a quick google search
<awygle>
I like magnet wire. Assuming that's the kind where the insulation melts.
<awygle>
Or is that kynar? Is there a difference?
<awygle>
whitequark: I don't have strands spread either, I just don't like the extreme change in properties from tinned to untinned. Solid is more uniform.
<whitequark>
I usually burn off PTFE insulation too :p
<TD-Linux>
it's mainly designed to cram as much copper as possible into a small area, hence the thin insulation. I've seen people use it for rework but it's not what I use
<TD-Linux>
my favorite is pre-cut wire-wrap wire. it is silver plated and takes lead free solder super easily. downside is that it's recently become expensive
<azonenberg_work>
i use kynar wire wrap wire for longer distance rework when i want to insulate the track, and when 30ga isn't too big
<azonenberg_work>
For really fine pitch stuff i use the circuitmedic "circuit tracks"
<azonenberg_work>
Which are basically rolled copper foil cut to the width of a standard pcb trace
<azonenberg_work>
i have i think 125 and 500 microns or something
<azonenberg_work>
rectangular cross section, bare copper
<whitequark>
nice
<awygle>
i have some kind of wire that's 30 AWG solid and the insulation melts/burns off easily, and that's all i know lol
<azonenberg_work>
whitequark: when you get a chance can you fix GlasgowSWDInterface to comply with my coding style?
<azonenberg_work>
in particular... if(foo) \n { \n (code here)
<whitequark>
azonenberg_work: do you think you can configure clang-format
<whitequark>
to do that automatically for all your projects
<azonenberg_work>
Not familiar with the tool and dont have time right now
<whitequark>
i can but i'd rather not manually remember a zillion styles
<whitequark>
ok
<azonenberg_work>
not a rush
<azonenberg_work>
Right now i am working on switching the jtaghal network protocol to be protobuf based so i can use swd from jtagsh
<azonenberg_work>
rather than trying to write a separate command shell for swd, etc
<azonenberg_work>
i have the protobuf schema done, just need to redo the marshaling/unmarshaling of data
<whitequark>
awygle: oh btw
<whitequark>
i killed an SWD port on a maple mini when plugging glasgow into it
<qu1j0t3>
whitequark | I usually burn off PTFE insulation too :p // impressive. PVC shrinks and chars if i glance at it, but even my too-hot iron can't hurt PTFE
<awygle>
ruh roh
<whitequark>
probably because during bus contention the FXMA oscillates and constantly outputs 35 mA
<whitequark>
qu1j0t3: i use a lighter lol
<awygle>
azonenberg_work: your brace style is that of a monster </unnecessary_judgement>
<qu1j0t3>
whitequark: I see! :)
<azonenberg_work>
awygle: visual studio style
<qu1j0t3>
whitequark: that's your stripping tool of choice?
<whitequark>
i dont care about most styles one way or another
<whitequark>
you could even use tabs
<awygle>
azonenberg_work: right, a monster :p
<azonenberg_work>
whitequark: i do
<qu1j0t3>
whitequark: (i've done that too...)
<whitequark>
just let me avoid doing it manually
<whitequark>
yeah i configured my editor for your projects
<whitequark>
have a separate config for them
<whitequark>
but it doesnt do braces
<azonenberg_work>
one \t = four columns = one level of indentation
<azonenberg_work>
Makes sense
<awygle>
something something structure editors :p open brace on same line, one hard tab per level, is my ideal. but i got sick of fighting that battle so now i'm on Team Autoformat
<azonenberg_work>
qu1j0t3: I use a Klein Tools wire stripper that does 30 gauge
<qu1j0t3>
i have a pair of really bad strippers
<awygle>
even though PEP8 is _terrible_
<whitequark>
awygle: re: bus contention
<qu1j0t3>
azonenberg_work: i think i've seen that one in a video. impressive
<azonenberg_work>
highly recommended and not expensive
<whitequark>
this means that the current limiting resistors are probably mandatory on fxmas
<whitequark>
and it's a wonder i havent killed the fpga yet
<whitequark>
would have thought that's less resilient than an stm32
<qu1j0t3>
azonenberg_work: Oh, no, that's not the same. looks nice though
<azonenberg_work>
i have several Klein strippers and am a big fan of the next size up as well, for house wiring
<awygle>
i'm not sure "constantly drives out 35mA" makes sense. it should hit the VCC level and stop. my guess is bad overshoot, which the resistors will definitely help and which is probably not as bad on the board as it is after long inductive wires
<azonenberg_work>
My only complaint is that it tops out at 10 awg
<azonenberg_work>
Which makes it difficult to use to strip 8awg wire :p
<awygle>
er, i guess it could out-source or out-sink the other driver...
<awygle>
which might cause damage
<gruetzkopf>
homedepot takes the nuclear approach to gdpr compliance..
<TD-Linux>
azonenberg_work, huh I have that exact same stripper, it's really good but had never seen others use it
<whitequark>
awygle: makes sense
<whitequark>
awygle: the thing is
<whitequark>
it doesnt hit the Vcc level and stop
<whitequark>
it oscillates
<whitequark>
really quickly
<whitequark>
all bus contention with FXMAs results in oscillation
<awygle>
hmm i see. because the source can overdrive the bus hold driver, but not the "fast edge" driver. that makes sense.
<whitequark>
exactly
<cr1901_modern>
Anything special about the number "35mA", or is just what you measured?
<awygle>
cr1901_modern: it's the rated current on the "fast edge" driver
<whitequark>
cr1901_modern: it's the datasheet figure for the edge driver
<cr1901_modern>
cool... just wondering
<awygle>
whereas the bus hold is like... 300 uA? i don't remember but it's small
<whitequark>
500 uA I think
<awygle>
anyway yes, i can see how that might burn the driver(s)
<awygle>
google sheets' habit of keeping everything i've looked at from the beginning of time leads to a very interesting history listing
<cr1901_modern>
same but w/ google docs
<awygle>
"SGMII Link Budget Analysis" "Hotstopper Inventory" "#DoesItFart" "ADC Analysis" "SM64 120 Star ABC Route" "YA Fantasy Literature wtih strong Female Protagonists in a D&D like setting"
<awygle>
followed by "Test" and "Whyyyyyyy?"
<cr1901_modern>
I was a fan of ABC before pannenkoek went viral. Then it wasn't as fun anymore to be a fan b/c everyone knew what ABC was
<awygle>
i feel bad for pannen, i'm glad they've been doing the uncommentated videos lately
<awygle>
i was worried the internet had ruined everything again
<awygle>
oh that's right my final math was in spice that's why i can't find it. oh well. exterior FXMA current should be ~4 mA with the new resistors, which shouldn't damage anything, hopefully.
<awygle>
the oscillations should be largely filtered out
<whitequark>
awygle: exxcellent
<whitequark>
remind me what is the value?
<awygle>
87 ohms, or whatever the closest E24 is to that value
<whitequark>
aha
<openfpga-github>
Glasgow/master d609d09 whitequark: applet.swd: add support for dormant-to-SWD transition for SWJ-DP.
<azonenberg_work>
whitequark: am i having to much fun in the laundry room? :p
<awygle>
i usually spec E24s because they're easier to source
<whitequark>
azonenberg_work: lol nice
<awygle>
and the difference rarely matters
<whitequark>
awygle: it was literally easier to get E48 from mouser
<awygle>
lol
<awygle>
shrug emoji
<whitequark>
seriously they were cheaper
<awygle>
i'm at work so i can't check what i actually ordered
<whitequark>
i think yageo just like... does better binning
<awygle>
i'm doing this from aided memory
<whitequark>
btw we do need E48 for analog parts
<awygle>
yeah, for sure
<awygle>
azonenberg_work: speaking of pipes - my new apartment building had a pipe separate and flooded the garage with 1000+ gallons of water three days ago
<azonenberg_work>
awygle: fuuuun
<awygle>
it was fine for me, my car isn't in the garage :p although the tires of my bike did get wet
<awygle>
i'm sure it was fun for the building people tho
<travis-ci>
whitequark/Glasgow#41 (master - 10b14c8 : whitequark): The build passed.
<whitequark>
gruetzkopf: >The main differences of theTPS65983B are that it has more ROM memory (10k vs 4k), it's PD 3.0 compliant, and it does non-thunderbolt systems as well as thunderbolt systems. Basically, the TPS65983B has more features than the TPS65983 and it's the same price (or similar). The TPS65983 is going to become NRD, so i highly reccomend to use the B version instead. I hope this helps :-)
<gruetzkopf>
they talk about "more rom" like it's a good thing
<gruetzkopf>
more RAM i could get behind
<gruetzkopf>
how is the PD complicance level hardware-limited?!
<whitequark>
looks like 65983B has a *different* mask ROM
<whitequark>
which makes zero sense
<whitequark>
how is that even related to TB/nonTB?!!!
<gruetzkopf>
no clue
<gruetzkopf>
*nothing* about TB seems to make sense
<whitequark>
ooooh found a project file for a TB3 dock
<gruetzkopf>
in ti e2e?
<whitequark>
yes
<whitequark>
schematics too lol
<gruetzkopf>
ooh i haven't found those yet
<gruetzkopf>
i have som prj file but not the specialsauce -b tooling
<gruetzkopf>
it's not interesting when you look at it with the easily available tool
<whitequark>
>This would be handled by the Thunderbolt controller. I believe the Coffee Lake RVP supports Thunderolt through the TR AIC, please refer to the 571483 Intel Document on page 7. The sleep and wake modes are connected to AIC through a GPIO header. The AIC could be implemented on the motherboard getting the PCIe from the PCH and graphics from the SoC.
<gruetzkopf>
that's a different pjt from the one i have iirc
<whitequark>
>However, the TPS65983B could allow an upgrade to PD3.0 if the hardware supports since the 83B has PD3.0 compatible silicon.
<gruetzkopf>
the txt file linked there is really a firmware image#
<whitequark>
yeah
<whitequark>
>The TPS65983 is to be used with TBT device reference designs. The 86 is very similar but does not run the TBT approved firmware. Also, the 86 does not have the gate drive for the external NFETs power path.
<whitequark>
what the fuck is "TBT approved firmware"
<whitequark>
is the only difference literally that the mask ROM in -83 is to Intel's liking
<rqou>
hmm at this point do we have enough information to build a "rogue" thunderbolt device? :P
<awygle>
seems unlikely
<rqou>
why unlikely?
<rqou>
there's that schematic on the forums
<rqou>
we can probably just copypasta some ROMs until we get the settings we want
<gruetzkopf>
we have the tools to tune them
<gruetzkopf>
but apparently there's some unknown magic missing
<rqou>
not the alpine ridge rom
<whitequark>
rqou: gruetzkopf: btw I found the SWD softstrap
<whitequark>
not fuse
<whitequark>
haven't tried to actually use it yet
<gruetzkopf>
should be easy to get from some laptops firmware
<gruetzkopf>
neat
<rqou>
btw whitequark the sonnet card has a really obvious swd debug header for the TI chips
<whitequark>
rqou: coooool
<whitequark>
rqou: i can get hte alpine ridge rom
<whitequark>
if i disassemble my laptop again
<whitequark>
it's one more 1 Mbyte flash
<whitequark>
they fucking love those things
<whitequark>
ibet it also has like 50 kb of firmware
<rqou>
unfortunately i believe the alpine ridge firmware is signed :(
<whitequark>
rqou: did you dump it already?
<rqou>
nope haven't touched anything
<rqou>
i wanted you to pick which one you wanted me to mail you first :P
<whitequark>
rqou: wtf what TI chip is that
<whitequark>
is that a TPS65983B
<rqou>
then I'll hack on the other one
<whitequark>
hell yes it is
<rqou>
don't see the -B though
<whitequark>
hm might not be -B
<whitequark>
rqou: can you dump the fw on that board
<whitequark>
i'll clone it
<gruetzkopf>
" It's not possible as Intel uses fixed settings which are not allowed to change and therefore these settings are not visible in the GUI." AAAAAAH
<gruetzkopf>
getting alpine ridge might be a problem
<whitequark>
into my adapter
<whitequark>
gruetzkopf: how so
<gruetzkopf>
like, aquiring parts
<whitequark>
alpine ridge is sold at mouser
<whitequark>
for like $10
<whitequark>
no docs tho
<rqou>
whitequark: does your sonnet box use the full pcie bracket or a short custom bracket?
<gruetzkopf>
and you actually get them without handing in proof-of-intel?
<rqou>
actually wait a sec
<whitequark>
it has a half height bracket
<whitequark>
gruetzkopf: yes
<whitequark>
the chips
<whitequark>
not the docs
<rqou>
whitequark: I'm not sure where the the TI chip firmware is on this card
<whitequark>
gruetzkopf: you can also get htem from macbooks that went into chipper
<whitequark>
the one on the front is virtually ertainly an spi flash
<whitequark>
the AR and the TPS can share the flash I think
<whitequark>
and one TPS can init the other TPS via UART
<whitequark>
rqou: yeah this is the flash
<whitequark>
I can see by the pinout
<rqou>
yeah that chip is certainly flash
<rqou>
it has a paint dot
<whitequark>
can you dump it
<rqou>
later
<rqou>
as long as you don't mind getting a board that has been hacked on :P
<whitequark>
absolutely not
<whitequark>
i have no issues with that
<whitequark>
wait why do you even need to hack on it?
<whitequark>
TPS tristates the SPI bus after boot
<whitequark>
and I bet AR does that too or it couldn't coexist with TPS
<whitequark>
you can just hook it up to a programmer or an LA
<whitequark>
actually yeah an LA trace will suffice
<whitequark>
you need at least 50 MHz to sniff TPS boot
<gruetzkopf>
i need a pack of soic8 sockets
GuzTech has joined ##openfpga
<whitequark>
rqou: And we use the TBT controller is Intel Alpine Ridge, which shared external flash is W25Q80DVSSIG, TPS65983 share this flash. The reference is “AR SP NGFF REV2P5_FINAL”.
<whitequark>
gruetzkopf: The x83 is made to support intel's TBT. The registers that are not seen on the GUI tool are locked because intel requires certian functionality to pass TBT cert.
<gruetzkopf>
maybe the location of the tps fw in the spi flash is the big difference?
<gruetzkopf>
and the spi tristate
<awygle>
sigh, this code does three passes over a multi-gigabyte file instead of one, no wonder this operation takes so long.
mumptai has quit [Read error: Connection reset by peer]
mumptai has joined ##openfpga
<whitequark>
gruetzkopf: >
<whitequark>
The TPS65983 will have an updated FW interface and an improved reset behavior for Two Port Alpine Ridge Systems. Please continue to use the TPS65982 until January when the TPS65983 releases.
<whitequark>
gruetzkopf: no
<whitequark>
they all tristate SPI
<whitequark>
and the location in the flash is in the first sector
<whitequark>
I can even modify it freely
<gruetzkopf>
i wonder where in flash alpinridge boots from
<whitequark>
lol
<whitequark>
>Could you guide me how to make(or send me the proper FW) the FW for 'Apex Creek based on TI (Rev 2.5) Reference from Intel' ?
<whitequark>
Samsung is making external GFX box with TPS65983 and asking FW of TPS65983
<whitequark>
>You can use the low region image to merge with the Intel Imaginarium tool.
<whitequark>
"Intel Imaginarium"
<whitequark>
jesus
<azonenberg_work>
???
<azonenberg_work>
what am i missing out on
<azonenberg_work>
(not sure i want to know...)
<rqou>
we're hacking thunderbolt to help whitequark yak shave
<jn__>
Intel… the company that manages to write a one-and-a-half pages long contract and NDA for a hackathon
* azonenberg_work
offers whitequark a chainsaw and weed whacker
<azonenberg_work>
you clearly have a lot of shaving to do
<TAL>
(on an AMD board, likely Threadripper due lack of lanes on smaller CPUs)
<whitequark>
I have a laptop personally
GuzTech has quit [Ping timeout: 245 seconds]
<whitequark>
gruetzkopf: The TPS65983 is a special product for ThunderBolt 3 devices (for example: hard drives, docks, and monitors) that connect to ThunderBolt 3 hosts (such as tablets, notebooks, and workstations)
<whitequark>
what the fuck
<whitequark>
why
<whitequark>
this explains why my laptop has a -82 though
<gruetzkopf>
i do not understand
<gruetzkopf>
why do apple laptops have -83 then?!
<TAL>
currently i'm using a kirby lake system with windows and have threadripper with linux, i would like to interconnect them just for fun
<rqou>
TAL: some guy demoed putting that into a threadripper
<whitequark>
gruetzkopf: *what*
<whitequark>
oh
<whitequark>
right
<rqou>
but wouldn't give too many details
<whitequark>
what the fuck
<TAL>
i mean my X399 Designare board actually has a header for a TB controller-board-thingy (which prob. will never be released)
<whitequark>
TAL: no you need the header for this alpine ridge card
<TAL>
but going over the stuff it really looks there is only USCI missing in the firmware/uefi
<TAL>
GPIO?
<whitequark>
its out of band power management
<whitequark>
yes
<whitequark>
via GPIO
<whitequark>
power and mode
<TAL>
ah ya
<gruetzkopf>
i don't understand why that's there at all
<gruetzkopf>
that could all be done over the pcie link
<awygle>
i suspect it represents some fault line in internal communications
<awygle>
i.e. there's a "power group" and a "high speed serial group" and they don't talk to each other
<TAL>
i think i just aquire a copy when that stuff gets available at good retailers
<whitequark>
lol
<TAL>
its just 50 bucks
<whitequark>
awygle: that sounds exactly like intel
<awygle>
it's Somebody's Law. maybe Hoffstader?
<TAL>
gruetzkopf: for easier debugging :P
<TAL>
hm rqou what i'm getting from this video "put USCI in the firmware and it should work"
<whitequark>
TAL: you need ACPI support
<whitequark>
UCSI lives in an SSDT
<whitequark>
you also need PCIe hotplug support in DSDT
<TAL>
true, but is support for it a hard requirement if the stuff would be all set up when powering on
<whitequark>
sort of
<whitequark>
gruetzkopf: >Are you going to building a thunderbolt ecosystem? If yes, you must copy exactly the intel reference design.
<whitequark>
wow
<whitequark>
they just answer with a variation on this every time
<whitequark>
and they dont even support some intel ref designs
<whitequark>
>1. If you are building a thunderbolt ecosystem, you should exactly copy the Intel reference, any change is highly not recommended including changing the DC/DC.
<whitequark>
> Since the TPS65983 is a thunderbolt device, the second I2C port will always go to a thunderbolt MUX. The other I2C port will go to an EC. This is why the address for only one of the ports is shown for the TPS65983 while both are shown on the TPS65982.
<whitequark>
hmm
<azonenberg_work>
whitequark: so basically any and all thunderbolt has to be an exact copy of that design?
<azonenberg_work>
sounds horribly fragile and untested :p
<azonenberg_work>
whitequark: btw so as part of my refactoring of the jtaghal protocol i am cleaning it up a bit, it should be simpler when i'm done
<azonenberg_work>
a couple of unnecessary messages are getting removed
<azonenberg_work>
(no changes to the user facing api)
<whitequark>
gruetzkopf: TPS65983(A) has 80 kB of RAM
<whitequark>
TPS65983B has 96 kB of RAM
<whitequark>
azonenberg_work: yeah
<whitequark>
>There are also two relevant code bases - 4.x and 6.x. Whenever you are designing devices from an Intel Reference design, it is important to use the 4.x / 6.x firmware codebase. (These firmware versions use Host Interface 2.0 spec.) This is because this is the firmware that these reference designs are validated with, and this is the firmware that is supported for use with these reference designs.
<whitequark>
>The release of the GUI that supports 4.x / 6.x firmware is named "TPS65983 GUI" and supports both the TPS65983A and TPS65983B devices. From your description, I believe that your previous product uses 4.x firmware on a TPS65983A device. In order to support PD3, you will need to move from 4.x firmware base to 6.x firmware base. PD3 support is the main difference between these two firmware bases.
<whitequark>
The 6.x firmware base, however, will not execute on a TPS65983A device because the 80 kB of memory on these devices is not sufficient, so in order to move to 6.x firmware base, you must also move to the TPS65983B device with the extra memory.
<whitequark>
holy shit
<whitequark>
they COULDN'T FIT PD3 into 80 KB OF RAM
<whitequark>
SO THEY MADE A SILICON REVISION
<whitequark>
my god this is the dumbest shit ever
<awygle>
lmao
<whitequark>
mystery fucking solved
* awygle
hums the schadenfreude song
<awygle>
i figured that was why, happy to have it confirmed
* jn__
draws an Intelexit logo
<azonenberg_work>
whitequark: loool
<azonenberg_work>
they did a die respin to get more ram?
<whitequark>
yes
<whitequark>
16k more ram
<whitequark>
to be precise
<whitequark>
ooo, I found some "intel confidential" reference designs
<whitequark>
sadly totally useless
<whitequark>
google cache is great
m_t has quit [Read error: Connection reset by peer]
<whitequark>
alpine ridge based schematic
<sorear>
They respinned and didn’t even double it?!
<gruetzkopf>
hmm
<gruetzkopf>
now i kinda want to squeeze PD 3.0 into less than 64kB
<gruetzkopf>
well "squeeze"
<rqou>
doesn't sound like this should be such a difficult squeeze
<gruetzkopf>
not really
<whitequark>
gruetzkopf: >I'm sorry that customer need PD3.0 and it's Dell'l dock project which's almost in MP status. I can't change device in this moment... Or you means 983B can't be use in dock tether with fully- featured cable?
<whitequark>
amazing
<gruetzkopf>
what kind of people work there?!
<whitequark>
> My customer response below issue from Intel's compliance test for Apple. They test this pass by using TPS65983A, but failed on TPS65983B. Do you have any idea about that?
<whitequark>
ahahahaha
<whitequark>
this is a goldmine
<rqou>
wait wait wait
<rqou>
"real" companies like dell and samsung are having trouble getting this to work too?!
<whitequark>
and apple.
<whitequark>
yes.
<gruetzkopf>
okay.
<rqou>
wait, _apple_ can't get their own tech to work?!
<gruetzkopf>
it's intels tech
<gruetzkopf>
i believe the "glue QSFP to laptop case" approach to this problem is looking better every day.
<rqou>
seriously, I've never heard of anywhere near as many issues with Ethernet
<gruetzkopf>
i've never had that many problems with plain pcie
<whitequark>
wtf
<whitequark>
I lifted someone's BPD config and this laptop still doesn't like it
<whitequark>
Are docks from other brands affected by this OS update?
<whitequark>
Yes, all brands of USB docking stations which use DisplayLink chips and drivers are affected. This includes Dell, Lenovo, Toshiba, Targus, Kensington, Anker, StarTech, etc. Regardless of brand, if the dock uses DisplayLink technology for graphics output, it will no longer function as expected after updating to macOS 10.13.4.
<gruetzkopf>
displaylink is pure usb though
<whitequark>
hm
<whitequark>
rqou: also yes AR has signed fw
<whitequark>
this is in intel tbt requirements
<rqou>
I wonder how many mac users are behind on updates due to bullshit like this?
<gruetzkopf>
is the config also signed?
<rqou>
i wonder if alpine ridge jtag is fused or not
<whitequark>
gruetzkopf: I think it verifies the PD fw signature only when updating through the AR chip
<whitequark>
because TPS doesn't have any way of signing fw
<gruetzkopf>
i mean the AR config
<rqou>
or whether alpine ridge has efuses at all
<gruetzkopf>
i've seen descriptors in the thunderstrike talks at ccc
<rqou>
i thought that was entirely pcie shenanigans?
<sorear>
how does PoE negotiation work?
<rqou>
azonenberg_work: ^
<TD-Linux>
power over ethernet? there's no negotiation
<rqou>
wait really?
<TD-Linux>
you just stick a 48 volt dc bias on
<TD-Linux>
if your device can't handle that it goes up in smoke
<rqou>
i know poe switches can report how much power had been requested
<whitequark>
no there's like three different incompatible PoE standards
<TD-Linux>
rip the tvs'es on my thinkpad t61p
<awygle>
yeah what whitequark said
<awygle>
the "i am a bias" is one of the old terrible "standards" iirc
<gruetzkopf>
it is, but he also looked at the TB controller to find out pinouts
<TD-Linux>
ah, maybe the equipment I was using just didn't follow the negotiation stuff
<rqou>
i really want to try to make a "rogue" tb device now
<TD-Linux>
indeed, all the ubiquiti stuff is just "passive"
<rqou>
meraki equipment actually does negotiation
<awygle>
i think for af the PSE checks a resistor
<awygle>
and for at there's an actual layer 2 negotiation
<awygle>
but you can also signal at with a particular resistance
<awygle>
something like that
<awygle>
and then there's four separate "non-standard implementations" lol
<awygle>
In 2014, Cisco created another non-standard PoE implementation called Universal Power over Ethernet (UPOE)
<awygle>
of course they did
<gruetzkopf>
most newer ubiquiti stuff is not passive anymore
<gruetzkopf>
but ieee PoE+
<whitequark>
gruetzkopf: >When building a TBT3 ecosystem, one must first contact Intel for a reference design that suits your application. Secondly, TI will provide the exact FW to flash the PD controller needed for your exact reference design (no customization on the GUI). Intel tells customers using TBT that customization is NOT allowed in order to have TBT certification. One must follow the reference design
<whitequark>
and copy all of the components used.
<whitequark>
With TBT devices, TI must follow what Intel tells us. I hope this answers your question, and for more details on TBT ecosystems, please contact an Intel Representative for assistance.
<gruetzkopf>
WTF
<rqou>
looool
<gruetzkopf>
so all TBT devices are essentially intel-designed
<whitequark>
yes
<whitequark>
this is absurd
<gruetzkopf>
wtf
<rqou>
is this why all TBT devices i see are all vaguely similar?
<gruetzkopf>
rqou: if you build a rougue TBT device i'll build a rogue TBT host
<rqou>
lol
<gruetzkopf>
alternatively, let's simply use proper pcie
<rqou>
we do eventually need to replace alpine ridge with an fpga though
<rqou>
need to talk to fruit computers
<gruetzkopf>
i have no idea how that side of the link works
<gruetzkopf>
i wonder how intel would react to a request on "tbt->oculink adapter"
Bike has joined ##openfpga
<rqou>
tbt->oscilloscope :P
<rqou>
although i wonder if NI has this already
<rqou>
gruetzkopf: tbt->train signalbox :P
<gruetzkopf>
none of the signalling computers i know have any DMA-capable bus
<whitequark>
gruetzkopf: IPoTB
<whitequark>
yes this exists, yes it is cursed
<rqou>
already exists
<rqou>
ATMoTB :P
<gruetzkopf>
i know this exists
<rqou>
SONEToTB :P
Bike has quit [Client Quit]
<whitequark>
TBoTB
<rqou>
lol
<gruetzkopf>
UTOPIA is such a great name compared to MII
<whitequark>
hm I wonder if I can crossflash TPS65983 with TPS65982 fw
<gruetzkopf>
1) desolder alpine ridge
<gruetzkopf>
2) add oculink connector
Bike has joined ##openfpga
<awygle>
i don't really get why IPoTB would be particularly cursed
<whitequark>
lol what the fuck
<whitequark>
i totally can
<whitequark>
it boots after crossflashing
<gruetzkopf>
:D
<gruetzkopf>
IPoIB is approximately as cursed as IPoTB (or would be, if not for the inherent cursedness of TB)
<awygle>
isn't IPoIB like, a primary use case of IB?
<awygle>
again, don't really get why it's cursed. but i haven't done much of anything with IB
<gruetzkopf>
IPoIB is what i use it for
<gruetzkopf>
cheapest way to get a 40G link for sure
<awygle>
mhm
<rqou>
fucky MTUs
<gruetzkopf>
but it's meant for other things
<gruetzkopf>
2044Byte
<awygle>
how is 2044 byte MTU fuckier than 1500
<rqou>
it's not 1500? :P
<gruetzkopf>
i do not want to unearth my cursed patchset
<rqou>
although the "just barely larger than 1500 because tunneling" is probably pretty cursed too
<rqou>
> Baby giant or baby jumbo frames are Ethernet frames that are only slightly larger than allowed by the IEEE Ethernet standards.
<gruetzkopf>
need to port it from FW to IB, should be significantly less cursed
<gruetzkopf>
hint: MSIs also work if RDMAd :P
<azonenberg_work>
rqou, awygle: note that despite all of the different poe standards
<azonenberg_work>
Its not the kind of mess usb pd is :p
<awygle>
so far any cursedness here seems like it can only exist at the driver level, which is a _far far cry_ from the level of cursedness TB is exhibiting lol
<rqou>
oh yeah i believe PoE operates completely autonomously from any actual data transferring
<gruetzkopf>
proposal: replace usb pd with 10mbit ethernet
<rqou>
it doesn't have a giant "alternate mode" trashfire
<awygle>
implementation plan: %s/pd/10BASE-T/g
<whitequark>
ahaha
<whitequark>
hmmm
<azonenberg_work>
gruetzkopf: proposal: replace usb for PC peripherals with 10baseT + PoE :p
<whitequark>
so Dell uses a custom SVID:MID pair for their TB dock, right
<whitequark>
wonder if I can emulate that
<gruetzkopf>
is it a TB dock?
emeb has quit [Quit: Leaving.]
<whitequark>
not sure
<whitequark>
let's see?
<gruetzkopf>
won't explode
<awygle>
azonenberg_work: proposal: implement usb-to-ethernet shim (both ways) on FPGAs in small form factor as transitionary measure
<whitequark>
yeah especially given that my hand slipped a while ago and I cut all USB lines on one side of the board
<whitequark>
:P
<whitequark>
still communicates via PD
<awygle>
see whether it actually works lol
<whitequark>
well it's broken in exactly the same way as before
<azonenberg_work>
awygle: honestly, usb 1.x isnt that complex and would work fine for keyboard/mouse
<gruetzkopf>
are you connecting anything to the high-speed pairs at all?
<gruetzkopf>
did i mention that i own a SCSI keyboard?
<azonenberg_work>
So usb 1.x to 10baseT would probably be bridgeable with a pretty trivial bit of RTL
<qu1j0t3>
gruetzkopf: interesting! had no idea those existed.
<gruetzkopf>
they don't really
<gruetzkopf>
it's from a CNC router that had no other external interfaces