<tnt>
esden: Any news on the icebreaker-bitsy btw ?
<tnt>
(sorry about the dupe, posted in the wrong chan ...)
unixb0y has quit [Ping timeout: 250 seconds]
unixb0y has joined ##openfpga
<esden>
tnt: nope, and I don't think there will be. I would have to take another deep look that is way beyond my current capabilities. The iCE40up5k seems to have too slow fabric to be able to implement full speed USB. Thus bitsy is likely out of the question, unless someone finds a way to get the bootloader to work on it.
<esden>
Also there seems to be jitter or some other issue if you try to use the PLL and multiply the external 12mhz clock to produce the 48mhz reference clock for the USB core. I am being told that this is the problem and can't be overcome. I really wish it was possible but the chances are very small at the moment. :(
<tnt>
esden: do you have any spare PCBs ? (even unpopulated ones)
<esden>
from my current playing around, even the simplest designs very quickly end up below 48mhz max speed constraint :( of course that is worst case assumption based on the data icetime has.
<esden>
tnt: I think I do have some boards from the last prototype run. I would have to look. I still want to assemble the newes prototype with 48mhz clock. I could send it to you if you want to have a stab at the issue. :)
<tnt>
esden: Yeah, I'd love to take a look at it. And I have a FSQ8 R&S spectrum analyzer with the phase noise analyzer option to check the clock. I also hacked up sigrok to my agilent scope to allow for USB low level debugging.
<esden>
sweet! that sounds awesome. I will try to dig up all the parts tomorrow and see if I can assemble two of them for you, one with the 12mhz clock and one with the 48mhz one.
<tnt>
I actually started working on my UP5k USB design again recently ... trying to design a minimal cpu softcore with USB Serial Engine.
<esden>
uhh that is very exciting, I would love to replace the stupid FTDI chip even on the large icebreaker, the ftdi chip costs as much as the damn fpga on that board >_<
<esden>
but we want to stay compatible with the dimond programmer software so we need to have that retarded chip on there :(
<tnt>
well ... you could emulate it :p
<tnt>
but I get what you mean.
<esden>
I couuuuuld :) but despite how much I hate FTDI as a company, I do not feel comfortable about doing this. Need to think about it bit more, maybe it makes sense to have a separate programmer software that can be used instead of the dimond programmer... not sure
<tnt>
I have never even used the diamond programmer. I didn't even know diamond could be used with the ice40, I thought it was all icecube.
<esden>
yeah it is strange icecube does not come with a programmer as far as I can tell... so you need to use that other thing to actually upload the bitstream, and it is horrificly slow too...
<esden>
it is all just hate inducing :D
<esden>
iceprog is shaping up a bit too, I have cleaned it up quite a bit, it now even works on some flash chips that dimond does not know about.
<tnt>
what's the motivation to stay compatible with the diamond programmer btw ? I mean iceprog works ...
<esden>
Still want to despagetti the code. I got the permission from Clifford to do that. :)
<esden>
maintaining a windows software :D
<tnt>
Well CLI tools aren't that hard, you can cross-compile with mingw pretty easily :)
<esden>
do not tell me that, tell that to the hard core windows 10 users that freak out when they see white text on black background ;)
<tnt>
Ah yeah, if you want a GUI, things get more complicated :(
<esden>
(I was showing Black Magic Probe and GDB one day to a CEO of a major open hardware company, he bluntly told me: you command line gurus, this is all over my head, our customers want things simple and graphical)
<esden>
I was genuinely shocked...
<tnt>
:O ... come on ... I would expect dev to be familiar with CLI tools.
<esden>
I completely lost respect for that guy :( I understand regarding some arduino only customers, but still you are a high tech company CEO! WTF
<esden>
Yeah, that is why we hang out here in our IRC ivory tower :P
<tnt>
lol
Bike has quit [Quit: Lost terminal]
<rqou>
whee, airbrushes are pretty cool
GenTooMan has quit [Quit: Leaving]
<azonenberg_work>
esden: he probably came from apple or something
<azonenberg_work>
i have zero interest in pandering to that crowd
<prpplague>
azonenberg_work: whaaat? i don't want to pander?
* prpplague
glares at azonenberg_work for being a non-pandererererrrr
<prpplague>
azonenberg_work: don't you have some remodeling to do?
<prpplague>
pics or it didnt happen
<azonenberg_work>
prpplague: lol
<azonenberg_work>
i have 2 pieces of sheetrock left to hang tomorrow, then a full day of taping and mudding
<prpplague>
ugh
<prpplague>
i hate that
<azonenberg_work>
and the bravo side of the garage will be ready for sanding
<prpplague>
i can understand now why those guys are paid so well
<azonenberg_work>
The delta side is pretty much virgin, insulated studs but no rock whatsoever
<prpplague>
azonenberg_work: funny though, for nearly 4 decades i dreamed of a lab for myself, now that i have it, i am too old and worn out to take advantage of it
X-Scale has quit [Ping timeout: 246 seconds]
<azonenberg_work>
prpplague: yeah i am determined not to let that happen
<prpplague>
azonenberg_work: yea just be careful of burn out
<prpplague>
(and getting old)
<esden>
azonenberg_work: no actually that person was from a much smaller company, founded by himself in his dorm room studying EE as far as I know... very surprising stance though, and quite close minded if you ask me... :( people that don't want to learn new things and dismiss stuff the way he did are very sad to me. :(
<azonenberg_work>
i avoid burnout the same way screensavers work
<azonenberg_work>
Keep moving around and doing different things so you're never stuck on one thing too long
<esden>
azonenberg_work: It is part of what allows me to work full time on the projects i work on, I have to pander to at least some degree to the customers. I am not very good at that though. Windows development is so unpleasant to me that I keep avoiding it until I find someone who is willing to do it for me. :)
<azonenberg_work>
The setup i am building is going to be a combined ~600 ft^2 of lab/office/conference room space
<azonenberg_work>
There's a 20x20 foot room with a partial wall down the center (former 2 car garage) that will contain an L-shaped soldering/test bench, a wet bench with fume hood and self-contained (no plumbing connection due to constraints of the way the building was made) sink
<azonenberg_work>
a microscopy bench
<azonenberg_work>
a bunch of storage, some uncommitted work areas
<azonenberg_work>
a rack of UPS, a rack of servers/FPGAs etc
<azonenberg_work>
Then on the other end of the building is a 10x20 foot room
<azonenberg_work>
logically two 10x10 foot spaces, at one side there's a desk for me and $wife and at the other side there will be a pull-down projection screen, some folding tables and chairs, walls lined with whiteboards, etc
<prpplague>
nice
<azonenberg_work>
There will be a small couch/loveseat against the wall that can serve as a waiting area
<azonenberg_work>
but the primary intended purpose is to fold up the conference room furniture, set it up in the middle of the room
<azonenberg_work>
and watch movies :p
<rqou>
wow prpplague your lab is so organized
<rqou>
why is my lab always such a shitshow?
<prpplague>
hehe, i dare not take a picture of it right now
<prpplague>
i haven;t cleaned in like 3 weeks
<prpplague>
it's a real shit show
<rqou>
you clean every 3 weeks?
<rqou>
that's way better than me
kuldeep has joined ##openfpga
<rqou>
my favorite "how to keep the lab clean" technique is still the technique my father used when he managed an r&d team in china
<rqou>
the solution is "rely on the cultural tradition of cleaning your house every chinese new year to mandate that the days immediately after the new year break are mandatory lab cleanup" :P :P
<whitequark>
holy shit
<whitequark>
the USB PD specification has FIVE PAGES of two columns of contributors
<rqou>
lolol
<whitequark>
and it is SIX HUNDRED PAGES LONG?!
<rqou>
yeah, afaik USB PD is a shitshow
<prpplague>
whitequark: USB = Unlimited Supply of Bugs
<prpplague>
rqou: well i try to do every sunday evening, so i can start fresh on monday
<whitequark>
the table of contents is 24 pages long
<rqou>
yeah schedules like that tended to piss off the hardware engineers who were constantly working on stuff
<whitequark>
"SOP/SOP' and SOP" are collectively referred to as SOP*"
<prpplague>
rqou: well unclean lab leads to accidents like stray bits of wire or screws shorting out "one of a kind" prototype boards
<rqou>
prpplague: can you backronym EFI/ACPI/PCIe as well? :P
<rqou>
prpplague: ahh, iirc very messy processes like that were confined to soldering stations that were cleaned more regularly
<prpplague>
Poorly Conceived by Idiots expansion
<rqou>
most of the hardware lab consisted of boxes that were at least reasonably stuffed into a chassis
<whitequark>
what's the problem with PCIe
<whitequark>
it's a nice bus
<rqou>
and then a giant sea of ethernet-cables-with-broken-tabs :P
<prpplague>
whitequark: meh, designed by commit bus stuff is never without issue imho, specially when Intel has a lead
<whitequark>
prpplague: what's the exact problem with it
* whitequark
stares at USB CC
<whitequark>
they put a... mini Ethernet into it
<rqou>
i would call marcan a problem with pcie :P :P :P
<whitequark>
like it uses biphase mark coding and 4b5b
<rqou>
oh wtf?!
<whitequark>
yep
<rqou>
why does it need that?!
<whitequark>
preamble for link training, SOF, message, CRC, EOF
<rqou>
link training?!
<rqou>
wtf are intel smoking these days?
<whitequark>
wow
<whitequark>
it has eye diagrams with requirements for 0 and 1 defined with piecewise linear functions
<rqou>
w t f
<rqou>
how fast does this thing run again?
<whitequark>
actually, no
<whitequark>
it has THREE eye diagrams
<whitequark>
for when you're sourcing power, sinking power, and power neutral
<whitequark>
WHAT
<rqou>
looooool
<whitequark>
hahahahaha
<whitequark>
it runs at
<whitequark>
300 kbps.
<prpplague>
whitequark: it's not that there is a specific issue with it, it's just that so many things about the specification are ambiguous that there is a lot of implementations that functional, and seem compliant, but don't offer solid cross compatibility
<rqou>
lolwat
<rqou>
i would have just said "stick a uart through a rs485 xcvr, done"
<rqou>
maybe with mandatory auto polarity swap
<whitequark>
yep
<whitequark>
same
<prpplague>
whitequark: hehe, you'll have to ask for more details another time, i've had 1/2 of a bottle of 30 year old rum, and i'm lucky i can type...
<whitequark>
uh
<whitequark>
why
<rqou>
btw does this spec explain how to interact with legacy short-the-data-lines PD or put-fruity-resistors-between-the-data-lines PD or i-love-patents-and-fancy-dsp-archs PD?
<whitequark>
why does it define a MULTIDROP BUS
<rqou>
hmm is this for many-port charge-only port banks?
<whitequark>
no
<rqou>
wait what
<whitequark>
the two additional drops are inside the cable's connectors
<rqou>
why do you need that?
<rqou>
for active cables?
<whitequark>
I'd have imagined active cables tunnel the CC through them
<marcan>
whitequark: but have you looed at what they did for SuperSpeed negotiation?
<whitequark>
but I guess not
<whitequark>
marcan: not yet
<marcan>
it has this low-power signaling thing
<marcan>
except it's not an actual protocol
<rqou>
how come SPFs in general "just work" (barring vendor lock-in) without even needing a formal spec?
<marcan>
it's like "burst at this frequency with these lengths mean this"
<marcan>
but they forgot about upwards compat
<marcan>
so SuperSpeed 3.1 had to do yet another fucking HS chirp thing
<whitequark>
hahaha
<marcan>
and now they encode data into particular burst lengths
<whitequark>
WHAT
<whitequark>
my god
<rqou>
wait is this just the weird low-frequency pulse trains that SATA/PCIe also use for various reasons?
<whitequark>
this is so fucked
<marcan>
using yet another fucking sub-protocol shoehorned into that
<marcan>
I mean FFS MIPI is better than this
<rqou>
marcan: does SuperSpeed have OTG?
<prpplague>
<marcan> I mean FFS MIPI is better than this
<marcan>
that's another thing
<marcan>
who initiates negotiation in SuperSpeed?
<marcan>
... both sides do
<rqou>
how would this functionality interact with legacy-style HNP/SRP?
<prpplague>
marcan: can i use that in my next engineering meeting?
<marcan>
they're supposed to *detect receiver termination*
<marcan>
and meet in the middle
<rqou>
wait, what if both sides do this?
<marcan>
they both do
<rqou>
what if both sides are OTG-capable?
<marcan>
and the spec doesn't have a single fucking timing diagram of what it's all supposed to look like
<marcan>
instead it has pages of state-machine-as-prose
<marcan>
and you kind of just hope it all works out
<rqou>
how would this functionality interact with legacy-style HNP/SRP?
<rqou>
does anybody actually even support legacy-style HNP/SRP other than TI's graphing calculators?
<whitequark>
huh they actually put 30V, 40V and 50V Vbus into the spec
<whitequark>
it also supports cables up to 300m
<whitequark>
that's three hundred
<marcan>
... over copper?
<whitequark>
no fucking clue
<rqou>
i mean, 10gbase-zr supports 80 km, does that count? :P
Miyu has joined ##openfpga
<rqou>
how come datacenter-grade ethernet managed to get everything to mostly work without even needing specs to be finished while USB manages to be a massive dumpster fire?
<marcan>
because intel
<rqou>
but intel also builds datacenter-grade ethernet
<rqou>
and those parts actually work
<marcan>
also I'm convinced USB is deliberately fucked up so that it's nigh impossible to build compliant silicon without paying the USB-IF
<rqou>
TB cables (thanks apple) also get nice and warm
<azonenberg_work>
marcan: and you wonder why i'm always pushing "ethernet ALL THE THINGS"?
Miyu has quit [Ping timeout: 240 seconds]
<rqou>
yeah, somehow despite a certain company naming all their products after missiles datacenter ethernet actually fucking works
kuldeep has joined ##openfpga
<whitequark>
oh and of course the USB PD protocol allows firmware updates for the plugs (both ends) and the device
<azonenberg_work>
lolol
<marcan>
:D
<rqou>
brilliant
<rqou>
BadPD when? :P
<azonenberg_work>
wow
* azonenberg_work
huggles a QSFP+
<azonenberg_work>
Mommy, save me from the big bad USB-IF!
<whitequark>
awygle: ok question, is it possible to use USB-C with USB 3 without touching USB PD
<whitequark>
because this spec is completely bonkers
<rqou>
i think you can wire yourself as a legacy downstream/upstream port?
<azonenberg_work>
whitequark: why would you use usb at all?
<marcan>
I think you need at least a mux for the superspeed lanes and a way of controlling that
<marcan>
which I think has to speak CC
<whitequark>
azonenberg_work: laptops don't have ethernet anymore
<whitequark>
marcan: :(
<azonenberg_work>
whitequark: You're clearly buying the wrong laptops
<whitequark>
azonenberg_work: nah
<marcan>
OTOH you can probably just buy chips that just Do This For You?
<whitequark>
the primary characteristic of a laptop i'm choosing it for (after a 4K IPS display) is weight
<whitequark>
so it's all ultrathins
<whitequark>
with XPS13 I finally found a laptop that it doesn't hurt to carry around
<rqou>
whitequark: i'm surprised you don't use a 51nb :P
<azonenberg_work>
whitequark: see, i used to have a big heavy 15" system76
<azonenberg_work>
now for work i have a t540p
<whitequark>
the USB PD spec defines 24 timers, each with their own time constant.
<azonenberg_work>
...
<rqou>
why are you using usb c anyways?
<whitequark>
dunno I hate the super speed micro connectors
<whitequark>
they're kinda shit
<rqou>
whitequark: can't you just use a HD3SS6126 and hardwire yourself as a UFP?
<whitequark>
ok so lol
<whitequark>
each USB-C power supply is actually a programmable power supply in disguise
<whitequark>
like there should be a device that adds knobs for setting voltage and current/power limits
<whitequark>
astounding
<rqou>
hmm i think the HD3SS460 is more appropriate?
<rqou>
you don't need superspeed gen 2 10gbps do you?
<whitequark>
no
<whitequark>
and yeah that works, thanks
<rqou>
yeah i think page 23 is basically what you need
<whitequark>
huh, that has type C routed out on 2 layers
<rqou>
anything faster please just give up and use SFP/QSFP cages?
<rqou>
i'm amazed anything in this ecosystem works
<rqou>
i guess that's why you can get a charging ouroboros
<rqou>
oh yeah whitequark do double-check if the example layout is for an upstream or downstream port :P
<rqou>
apparently that's a classic way to fuck up displayport
<whitequark>
"Vconn Source gets the Cable Plug's Country Codes"
<whitequark>
lol half of the specification is just very verbose descriptions of flows for every single pair of request-response
<whitequark>
looks autogenerated
<whitequark>
XML was probably involved
<rqou>
not perl? :P
<rqou>
the missile-chip company had both perl and xml involved in the docs workflow :P
<whitequark>
there are 6 pages that only enumerate "Policy Engine" states in one gigantic table
<whitequark>
the sections are nested seven levels deep
<rqou>
damn modern intel's got some nice drugs
<whitequark>
ok, now it's talking about USB descriptors.
<whitequark>
I thought it just talks over the CC pins
<rqou>
lol nope
<rqou>
they came up with a "billboard" device class
<rqou>
iirc so that a device can tell you that it doesn't support the alternate function advertised
<whitequark>
no
<rqou>
no?
<rqou>
well, this feature also exists
<whitequark>
it honest to god supports power delivery requests over USB per se
<rqou>
so it must be in a different part of the spec :P
<whitequark>
like Get_Battery_Status
<rqou>
wtf
<whitequark>
lol it has a demonstration of calculating CRC
<whitequark>
... in excel
<rqou>
loooool
<whitequark>
... pasted as a screenshot
<azonenberg_work>
.......
<rqou>
unfortunately i cannot say that i've never seen that before
<azonenberg_work>
that is worse than matlab
<rqou>
remember, i worked at names-chips-after-missiles company
<rqou>
i.e. a Vendor(TM)
<whitequark>
>Click the word "Request", sign in with your myTI username/password, and fill out the short form to add the TPS65983 to your list of devices with mySecureSoftware privileges. Then you will be able to download all of the additional FW documentation and the TPS65983 Configuration Tool. The Tool will let you open and customize the default standard FW images (.bin binary files).
<whitequark>
AAAAAAA
<rqou>
if you need me to try and register with a .edu email, feel free to ask me
<marcan>
whitequark: so apple. do you know about how the Lightning to HDMI adapter works?
<whitequark>
yes.
<rqou>
yeah, it has a whole soc in it that runs a darwin kernel
<whitequark>
unfortunately.
<marcan>
:P
<marcan>
all because Lightning cannot pass USB3 or HDMI or anything sane
<marcan>
because it was designed by designers instead of engineers
<rqou>
what a piece of shit design
<rqou>
it even has that fancy tristar mux + drm thingy
<whitequark>
marcan: who do you think designed USB C?
<marcan>
USB C is the other end of the spectrum, "let's make it do all the things"
<marcan>
throw more lanes in there! and sidebands!
<rqou>
but hey, lightning has sidebands too
<rqou>
some french guy can even abuse them to get kernel debug messages
<marcan>
re: USB C power supplies, guess how many out there don't even have the required programmable switch and just hardwire 5V to the output (which is dangerous because you can short two together)
<marcan>
hint: lots
<whitequark>
aaaaaugh
<marcan>
but if all you're doing is 5V I don't think you need to have any control over the output besides the switch
<marcan>
rqou: it has two lanes, not sidebands, IIRC
<marcan>
and one lane can be muxed to the uarts, sure
<rqou>
i thought it had a slow one-wire sideband too?
<marcan>
(this was actually well known, that guy was just apparently the first guy to bother to figure out the magic voodoo to make the switch flip that way)
<marcan>
yeah it has some 1-wire thing for control?
<marcan>
but I think the uart just gets put into one pair
<rqou>
hmm idk
<rqou>
unfortunately i heard that apple fixed his backdoored nvme pcie trick on newer socs
<marcan>
they have an IOMMU anyway
<rqou>
supposedly the older ones didn't?
<rqou>
or somehow did it wrong
<marcan>
I think they all did? not sure though
<marcan>
might've been programmed wrong or just exploiting the driver
<rqou>
yeah idk
<marcan>
IIRC when I read that french guy's pages it was severely lacking in info
<rqou>
yup
<marcan>
never really detailed what he did
<marcan>
and I asked some apple guys and they said they thought some of it was BS
<marcan>
as in he was saying he did things one way but it was actually something else
* marcan
dislikes people who write information-light misleading posts like that
<rqou>
yup, me too
<whitequark>
hm, the TPS65983 firmware is exactly 64k in length
<whitequark>
doesn't seem to be encrypted
<whitequark>
weird
<rqou>
not compressed?
<whitequark>
it might be compressed
<rqou>
i was noticing the words near the word "Apple" were all a bit weird
<whitequark>
yes
<rqou>
possibly yet-another-lz-variant?
<whitequark>
but it has a bunch of other strings that are intact
<rqou>
not uncommon for lz-variants
<whitequark>
hm ok
<rqou>
iirc ath10k firmware looked like that too
<marcan>
you know about QuickBMS?
<rqou>
oooh this guy
<whitequark>
oh I was about to ask
<rqou>
i've been on his page over a decade ago
<marcan>
it's amazing. it supports like 700+ compression algorithms. you can throw a raw bitstream at it and see what comes out
<rqou>
but i didn't know about quickbms, no
<marcan>
found an LZSS variant used by Joysound on Switch in a couple minutes
<whitequark>
now that I think
<whitequark>
binwalk reported a pretty high entropy for the entire firmware
<whitequark>
around 0.85
<whitequark>
so yeah it's likely compressed
<rqou>
marcan: i had visited their webpage over a decade ago because i was really really interested in the fact that 11919756538899982707863945724539333653761979774857340612183031053510579734245760842675696123649067370696469454488556563414740486190448071046262068092920827 factors into 107598980472254386795045147913543862508113336591870024651740038727775424413563 and 11077945614896998628373179020793102666975995412530198
<rqou>
2507683967583823729542529
<rqou>
(this is now fixed unfortunately)
<marcan>
what's that private key for?
<rqou>
i didn't say anything about a key :P
<marcan>
sure you didn't :P
<rqou>
it's just some prime numbers :P :P
<rqou>
nProtect GameGuard
<marcan>
ha
<rqou>
it now has an rsa2048 key
<rqou>
i decided to factor it back in 2009-2010 after i learned that it was possible
<rqou>
thanks to the TI calculator keys being factored
<marcan>
neat
<rqou>
eventually i discovered that some chinese cheaters had also realized the same thing :P
<rqou>
which is what probably prompted the switch to a new key since i never weaponized mine :P :P
<marcan>
fwiw, here's how to brute force a compression algo on quickbms on linux: for i in $(seq 1 800); do src/quickbms -a "$i [expected_output_size]" comtype_scan2.bms [input file] [output dir]; done
<marcan>
and expected_output_size should probably be larger than the real one
<marcan>
that way, if you know the expected output size, you can look through the output directory for files that match
<marcan>
and that narrows it down to a few variants of the correct algorithm
<marcan>
(for me it was basically a couple LZSS variants that differed only in how the dictionary was initialized and how it was indexed, which obviously produce identically sized output but with differences)
<whitequark>
marcan: i have no idea what the expected output size is
<rqou>
hmm i just remembered that iirc some people found a bootrom bug for the TI calculators
<rqou>
but idk if anybody did a full write-up
<marcan>
whitequark: presumably there's some header?
<whitequark>
hm it has a CRC
<whitequark>
which might be a post-decompression CRC
<whitequark>
marcan: there is a header
<whitequark>
but it just tells me where the application code is
<whitequark>
not how large it is
<marcan>
hm, well, just guess something reasonably large and then use some other way to narrow down the outputs
<whitequark>
oh I know
<whitequark>
I can grep for "Apple Thunderbolt"
<whitequark>
in UTF-16
<whitequark>
oh
<whitequark>
I think it's prefixed with the size
<whitequark>
73952
<marcan>
that would make sense
<marcan>
is this some LZ variant? typical 0xff <8 bytes of plaintext> 0xff <8 bytes of plaintext> stuff?
<marcan>
I still need to go back and finish reversing that Lenkeng HDMI encoder LZ variant
<marcan>
okay, so not that family of LZ. wtf is up with those 0x12?
<marcan>
*that* is bizarre
<marcan>
I see lots of 0x12
<marcan>
is that replacing 0x00 somehow?
<whitequark>
probably
<marcan>
the first screenshot you posted looks like some kind of table
<marcan>
and then actual data later
<whitequark>
yeah it kinda does
<whitequark>
wow, why does openbms build with -m32
<rqou>
lol
<rqou>
64 bit porting is teh hardz?
<whitequark>
no it builds with -m64 on darwin
<rqou>
loool
<whitequark>
also it builds with -O0 and -fno-unit-at-a-time
<marcan>
yeah it's... messy
<whitequark>
> -m32 because QuickBMS has been tested only on 32bit systems and gives problems using 64bit native code
<whitequark>
gods
<marcan>
I'm making no claims as to the quality of the code whatsoever
<whitequark>
EXTRA_TARGETS= libs/amiga/amiga.s
<whitequark>
what
<marcan>
but damn if it isn't handy for what it does
<rqou>
lolol
<whitequark>
...
<whitequark>
that's
<whitequark>
that's 68k assembler automatically translated into x86
<rqou>
is today shitty engineering day or something?
<marcan>
once it found the algorithm I actually spent 10 minutes just digging through the code to *find* the code responsible for that ID
<marcan>
still saved me time overall though :P
<marcan>
(then I rewrote it in python)
<whitequark>
-3 execute an INT3 before each CallDll, compression and encryption
<whitequark>
Features and security activation options:
<whitequark>
why
<whitequark>
-g enable the usage of video graphic device
<whitequark>
-m enable the usage of Windows messages
<whitequark>
what
<whitequark>
why
<whitequark>
this is horrifying
<rqou>
people are bad at programming?
<marcan>
I think there's some kind of emulation crap involved?
<marcan>
I mean it does more than just compression
<rqou>
why do so many people like to NIH compression?
<rqou>
i don't get it
<rqou>
i find compression pretty boring
<marcan>
the stuff I used was using NIH compression... side by side with a PNG. which uses zlib.
<marcan>
of course zlib is way better than their NIH compression.
<rqou>
classic nintendo
<azonenberg_work>
The only time i've DIY'd compression is RLE on a logic analyzer to save sample memory
<azonenberg_work>
And that was only because I needed minimal gate count and single clock cycle performance
<azonenberg_work>
and compression ratio was kind of an afterthought
<rqou>
something like that actually makes a bit more sense
<rqou>
what i don't get is people who love to NIH LZ-variants
<rqou>
when there are perfectly good algorithms that you don't have to NIH
<marcan>
I've DIY'd RLE a few times where it had significant savings and the decompressor is like 5 lines of code
<marcan>
but that's it
<azonenberg_work>
Yeah exactly
<azonenberg_work>
Anything more complex than RLE makes little sense to DIY
<marcan>
I don't get NIHing LZ variants
<marcan>
just why
<azonenberg_work>
I'll be honest, i might roll my own deflate core in an FPGA if i needed it and the alternative was an expensive commercial IP
<azonenberg_work>
But it would be actual zlib-compatible deflate
<marcan>
:D
<azonenberg_work>
(i havent checked if there are any *good* f/oss deflate IPs)
<rqou>
yeah, something compatible with an existing algorithm might make sense
<rqou>
but lots of people seem to like things like "oh yeah, i remember LZ from university, herp derp let's code it (and possibly introduce some exploitable bugs along the way)"
<azonenberg_work>
lol
<azonenberg_work>
rqou: now imagine those people trying to crypto
<rqou>
also people using deflate wrong is fun
<azonenberg_work>
and you'll understand why i have a job :p
<azonenberg_work>
if only you had seen the things i've seen
<azonenberg_work>
time seeded rand() isn't even the worst offender
<rqou>
marcan: altera managed to hide their compressed data from binwalk by failing to actually ever terminate their zlib streams
<azonenberg_work>
(for key generation)
<marcan>
rqou: lol
<rqou>
they just ended everything with a fully-flushed block but no trailer
<azonenberg_work>
rqou: i doubt that is deliberate obfuscation
<rqou>
binwalk was sad
<azonenberg_work>
its probably just them failing to call the close function
<rqou>
but they somehow remembered to call flush instead
<rqou>
i guess it usually doesn't work if you don't do that :P
<rqou>
azonenberg_work: have you ever seen the ardui-noob suggestion of "use the value on a floating analog pin as random seed"?
<azonenberg_work>
rqou: lol
<marcan>
lol.
<rqou>
wait, have you?
<azonenberg_work>
Yes
<rqou>
wait wtf
<marcan>
sounds like typical ardui-noob
<rqou>
in production?
<azonenberg_work>
Oh, no i have not seen it in prod
<azonenberg_work>
but i've seen it proposed
<rqou>
wat
<rqou>
i guess now i understand why scanlime was quite unhappy with it
<azonenberg_work>
The legitimately *best* idea i've come up with for randomness on an FPGA is to use the XADC to sample an actual diode noise generator
<rqou>
meanwhile my thoughts were "meh, nobody would actually _do_ that right?"
<azonenberg_work>
Then feed that (among other things like metastability from async clocks etc) into an entropy pool
<azonenberg_work>
then use that pool to seed a stream cipher
<azonenberg_work>
something along the lines of yarrow or whatever its successor is (forget the name)
<azonenberg_work>
rqou: about six months ago
<azonenberg_work>
actually no, more like a year ago?
<azonenberg_work>
i was doing a pentest on a webapp for $HUGE_CORPORATION
<azonenberg_work>
and of course i pwned it up the wazoo
<azonenberg_work>
you know what the vuln was?
<rqou>
sqli?
<azonenberg_work>
literal textbook sql injection, no filtering or anything
<rqou>
wait wtf
<rqou>
are you serious?
<azonenberg_work>
SELECT * FROM table WHERE id = $_GET['id']
<azonenberg_work>
pretty much
<rqou>
devs should be fired
<marcan>
color me unsurprised
<rqou>
$WORK's favorite vuln actually used to be _command injection_
<azonenberg_work>
marcan: not surprised, just sad
<rqou>
not sql injection
<marcan>
how long did the php world teach people to use fucked up escaping functions instead of, you know, parameterized queries?
<azonenberg_work>
rqou: oh i've seen a lot of that too
<marcan>
it took until PHP7 for them to remove the stupid legacy API
<rqou>
we've since fixed it by patching the php interpreter to automatically block command injection
<azonenberg_work>
marcan: which legacy api?
<marcan>
mysql
<azonenberg_work>
magic_quotes_gpc?
<marcan>
as opposed to mysqli
<azonenberg_work>
:p
<rqou>
mysql_fake_escape_string? :P
<marcan>
and even with PHP7 you just *know* some idiot is going to keep interpolating SQL themselves
<marcan>
and fucking it up
<whitequark>
marcan: lol openbms wrote a 1128M file
<whitequark>
even though I told it to not gobeyond 4k
<marcan>
what
<marcan>
lol
* azonenberg_work
sleep
<whitequark>
holy shit
<whitequark>
95.dmp contains some sensible strings
<whitequark>
they're very badly mangled but
<marcan>
less than in the original compressed stream?
<whitequark>
the original compressed stream, or rather a chunk I took out of it that followed what I thought was a sensible length field
<whitequark>
the TPS65982 one is ALSO export-controlled but they let you clickwrap
<whitequark>
this is so hilariously fucked
<rqou>
wait how is this part different?
<rqou>
i hate all of these TPSnnnnn part numbers
<whitequark>
I have no idea
<whitequark>
it seems practically identical but they reflow the datasheets
<whitequark>
so it's hard to compare word for word
<whitequark>
oh hm
<whitequark>
TPS65983 is Thunderbolt-exclusive
<whitequark>
TPS65982 isn't
<whitequark>
though there's nothing Thunderbolt-specific in TPS65983 as far as I can tell
<rqou>
lolwtf
<whitequark>
is this somehow related to Apple banning all the TPS65983A adapters and mandating use of TPS65983B?
<rqou>
wait they did?
<whitequark>
which is also almost exactly identical to TPS65983
<whitequark>
yes
<whitequark>
the driver has a table
<rqou>
how?
<rqou>
W H A T
<whitequark>
if the PID matches then it doesn't try to set up the Thunderbolt link up
<whitequark>
seriously
<whitequark>
people even patched it out
<whitequark>
in the kext
<whitequark>
this is the most hilariously fucked shit I've ever seen
<rqou>
is the PID firmware-controlled?
<whitequark>
yeah
* rqou
flips a table
<whitequark>
oh?
<whitequark>
what about it?
<rqou>
does that mean you can just crossflash them?
<whitequark>
yes, assuming you know how to flash them over USB
<whitequark>
because otherwise you have to spend like a hour with a dremel
<whitequark>
no idea if TPS6598x supports the USB PD flash request
<whitequark>
or if it's signed
<whitequark>
let's run their config tool
<rqou>
whelp, i guess you didn't actually need me to try the .edu magic?
<whitequark>
no, I do
<whitequark>
the config tool doesn't handle TPS65983
<rqou>
wtf
* rqou
flips another table
<whitequark>
only TPS65982 and TPS65986
<rqou>
this is retarded
<whitequark>
because that makes sense
<whitequark>
yes this is
<whitequark>
aha
<whitequark>
"Host Interface FW Update"
<whitequark>
lol their tool ships with Qt and tcl/tk
<rqou>
better than motif :P
<whitequark>
...
<whitequark>
they do have some tps65983 code in it
<whitequark>
tps65983_register_definitions.py
<whitequark>
oh yeah it ALSO ships Python
<rqou>
whee, half-complete fruit company redactions ftw
<rqou>
BRCM managed to accidentally reuse a PCI id thanks to fruit company :P
<whitequark>
tps65983b has like two times the registers tps65983a has
<rqou>
wtf
<whitequark>
it is an "exact replacement" according to ti
<whitequark>
what the ever living fuck is going on
<rqou>
fruit company lol
<whitequark>
>Audit Right. At TI's request, and within thirty (30) calendar days after receiving written notice, you shall permit an internal or independent auditor selected by TI to have access, no more than twice each calendar year (unless the immediately preceding audit revealed a discrepancy) and during your regular business hours, to all of your equipment, records, and documents as may contain information
<whitequark>
bearing upon the use of the Licensed Materials. You shall keep full, complete, clear and accurate records with respect to product sales and distributions for a period beginning with the then-current calendar year and going back three (3) years.
<whitequark>
holy shit
<whitequark>
>12.PRC Provisions.
<whitequark>
>e.Restrictions. You shall maintain the source code versions of the Licensed Materials under password control protection and shall not disclose such source code versions of the Licensed Materials, to any person other than your employees and contractors whose job performance requires access.
<whitequark>
>You may use the Licensed Materials with Open Source Software or with software developed using Open Source Software tools provided you do not incorporate, combine or distribute the Licensed Materials in a manner that subjects the Licensed Materials to any license obligations or any other intellectual property related terms of any license governing such Open Source Software.
<whitequark>
wow
<whitequark>
this is incredible
<rqou>
sounds very fruit company
<whitequark>
AHA
<whitequark>
I coerced the tool into reading the right region of the TPS65983 firmware
<whitequark>
and it actually matches the FW version from strings dump
<rqou>
so is this uncompressed?
<whitequark>
" Version 2.x of the tool replaces node-webkit with Qt using PySide Qt python bindings."
* whitequark
stares
<whitequark>
rqou: no, it's compressed
<rqou>
aw
<whitequark>
but the FW version string either doesn't compress well, or is in an uncompressed part
<whitequark>
wait
<whitequark>
how did they manage to write a tool that uses BOTH node-webkit and python
<rqou>
in totally unrelated news, china has a really clever way to make "yellow" EL wire
<rqou>
> can't engineer good yellow phosphor
<rqou>
> engineer good green phosphor, wrap wire in yellow plastic
<rqou>
anyways, sounds like your typical intern tool :P
<rqou>
in further random unrelated news, copper wire is a surprisingly good biocide
<whitequark>
holy shit
<whitequark>
every single device template in the tool is a 9000-line Python file that sets up the entire GUI from scratch
<rqou>
blame interns :P
<whitequark>
lolsob it has a TPS65983 firmware and templates
<whitequark>
they're just renamed
<whitequark>
and outdated
<rqou>
looool
<whitequark>
holy shit
<whitequark>
the project files are ALSO gigantic python blobs
<whitequark>
they just have JSON with settings appended
<whitequark>
this is incredible
<whitequark>
oh cool, it has been processed with py2exe but it still has all the doc comments
kuldeep has quit [Ping timeout: 252 seconds]
kuldeep has joined ##openfpga
<whitequark>
rqou: this is really depressing
rohitksingh has joined ##openfpga
<whitequark>
i decompiled the entire thing but it's too enormous to figure out anything useful
<whitequark>
azonenberg_work: any idea what CRC has polynomial 104C11DB7?
rohitksingh has quit [Quit: Leaving.]
<whitequark>
oh IEEE 802
kuldeep has quit [Ping timeout: 250 seconds]
kuldeep has joined ##openfpga
<whitequark>
rqou: I found out how to crossflash them via USB
<whitequark>
ok, correction
<whitequark>
how to write registers
<whitequark>
not sure if you can actually crossflash, but you can definitely change PID
pointfree[m] has quit [Remote host closed the connection]
jfng has quit [Remote host closed the connection]
indefini[m] has quit [Write error: Broken pipe]
thehurley3[m] has quit [Remote host closed the connection]
Wallbraker[m] has quit [Remote host closed the connection]
AlexDaniel-old[m has quit [Remote host closed the connection]
nrossi[m] has quit [Remote host closed the connection]
rohitksingh has joined ##openfpga
Wallbraker[m] has joined ##openfpga
<cyrozap>
whitequark: Ok, I read a bunch of the scrollback for today, but I couldn't figure out why you're trying to reverse engineer some TI Thunderbolt IC. Also, Intel lets other companies make TB ICs? I thought they were the only ones with TB->PCIe chips...
<cyrozap>
And what are you building that uses USB 3/Type-C/PD?
<whitequark>
rqou: LOL
<whitequark>
I ported the TI tool to Linux
rohitksingh has quit [Quit: Leaving.]
<whitequark>
cyrozap: I want to have a eGPU work with my laptop
<whitequark>
this has been... unusually involved so far
<cyrozap>
whitequark: Oh, so the IC RE and the USB PD and the USB 3 mux stuff is all related?
<whitequark>
yes
<whitequark>
no
<whitequark>
USB 3 mux isn't
<whitequark>
it's for a hypothetical successor of Glasgow
<whitequark>
the rest is
<cyrozap>
Ahhhhh, I see...
X-Scale has joined ##openfpga
<cyrozap>
I was just curious because I recently became interested in Thunderbolt and TB docks so I downloaded the firmware updaters for a couple and took a look at their firmwares.
<cyrozap>
I only got as far as extracting the .NET resources for the firmware binaries and running cpu_rec on them before getting bored :P
oeuf has quit [Read error: Connection reset by peer]
<cyrozap>
This was for Intel-based TB docks, btw.
oeuf has joined ##openfpga
<cyrozap>
According to cpu_rec, these things have 8051 and Xtensa cores in them.
<cyrozap>
I was hoping that maybe it'd be possible to build a PCIe to TB host adapter card, so normal non-Intel PCs can get Thunderbolt ports.
<whitequark>
cyrozap: uh
<whitequark>
you can literally just buy these things
<cyrozap>
whitequark: Check again, they only work on certain Intel motherboards with a special header.
<whitequark>
the fuck?
<cyrozap>
"thb_c header pins on motherboard required. Does not state this in description. If your motherboard does not have a thb_c pins on it you cannot connect the required thb_c header from the card to the motherboard and the card will not work. This should be plainly described in the description. Wasted my time buying it."
<whitequark>
oh
<whitequark>
facedesk
<whitequark>
this is absolutely ridiculous
<whitequark>
I know why it needs that
<whitequark>
but it's absurd
<whitequark>
it needs that to talk to ACPI
<cyrozap>
Wait, it has a hard dependency on ACPI?
<whitequark>
on non-Apple PC, yes, the ACPI tables and firmware must be explicitly set for PCIe hotplug via Thunderbolt
<whitequark>
and you also need something in SMM
<whitequark>
not sure what exactly, none of them fess up
<whitequark>
you need the unholy trifecta of ACPI/SMM/EFI to cooperate and this is why it works like shit
<whitequark>
i mean it mostly doesn't
<cyrozap>
...
<cyrozap>
Fuck Intel
<cyrozap>
🖕🖕
<lain>
wow.
<lain>
that's an impressive mess
<lain>
can't wait to get this arm laptop project done so I can stop having to think about intel
<cyrozap>
lain: You should buy a Talos II. They're great systems, especially if you dislike having money as much as you dislike Intel :)
* cyrozap
sobs in POWER9
<lain>
haha
<lain>
yeah POWER9 looks great
<lain>
but money :<
<whitequark>
rqou: it's not compressed
<whitequark>
most of the firmware is just thumb code
<whitequark>
not sure what's up with strings
<lain>
cyrozap: we're using a Marvell ARMADA 8040
thehurley3[m] has joined ##openfpga
pointfree[m] has joined ##openfpga
jfng has joined ##openfpga
nrossi[m] has joined ##openfpga
AlexDaniel-old[m has joined ##openfpga
indefini[m] has joined ##openfpga
<cyrozap>
lain: Also, PCIe link training fails for some cards on my system... but hey, at least the firmware is FOSS so I can fix it!
<jn__>
lain: oh, you're designing another ARM laptop? cool
<cyrozap>
lain: Isn't the ARMADA 8040 a little beefy for a laptop?
<cyrozap>
And the cheapest dev board for it is $$$
<lain>
cyrozap: life goals: laptop that can act as an impromptu 10 GbE router/switch
<cyrozap>
and it's made by Marvell :P
<lain>
the MACCHIATObin single shot board is only a few hundred USD$
<lain>
yeah, Marvell is not great unfortunately
rohitksingh has joined ##openfpga
<lain>
NDAs may or may not have been involved, which limits the scope of how much we can open on this project, but at the moment the primary target is "we want a spiffy arm laptop that we have full access to".. public open source stuff is a secondary goal for this one
<lain>
we also looked at NXP QorIQ LS2000-series, one of which was an 8-core monster
<cyrozap>
I was considering getting a MACCHIATObin, but IIRC it still requires a bunch of blobs and I don't want to trust my home networking to something running mystery code, especially if that something costs $350.
<lain>
sat down with FAEs at the local distributor for NXP, got all the access we wanted, just needed to confirm pricing and sourcing, and things just went south fast
<lain>
for months, every request the distributor put in for pricing came back from NXP as "we don't sell that part number" or "that's an obsolete part"
<lain>
when they finally started getting possibly-valid information back, the distributor had a major software changeover and the new system collapsed immediately, so they were backed up helping bigger customers etc
<lain>
after like 6 months we just gave up trying to get anything out of them and started looking at Marvell again
<lain>
we're a lot happier with the ARMADA 8040 though
<lain>
cyrozap: I have to be careful here because NDA, but iirc there's only one blob, which is optional (used for power management)
rohitksingh has quit [Quit: Leaving.]
<lain>
based only on public information we amassed before NDA, I can tell you the blob runs on a Cortex-M3, is not protected in any way that I'm aware of, and runs FreeRTOS
<lain>
this can all be readily deduced with a quick peek on their wiki
<lain>
other than that, there IS a bootrom, which I haven't looked closely at yet, but it's probably fine imho
<cyrozap>
lain: Yeah, I'm not concerned about the bootrom, I just saw some stuff on a tech brief that said it had a "security processor" and I always get wary when I see something like that
<lain>
ahhh that
<cyrozap>
Also I thought there were other cores that might run firmware, like maybe the built-in ethernet switch or other cores, but I might be misremembering
<cyrozap>
Also, possibly DDR training code
<lain>
unfortunately I can't say anything about the security processor other than a quick look suggests it is harmless
<lain>
I don't think there's anything else with firmware but we will definitely be taking a hard look at all of that :3
<lain>
there's ATF (ARM Trusted Firmware iirc?), but I think that's all on github
<lain>
the source code, I mean
<cyrozap>
Oh, yeah, there was also a "management subsystem" on the block diagram. That makes me think of things like "Intel ME", but maybe that's just the ATF SCP/Cortex-M3?
<cyrozap>
Also, blob-free DDR init is important, too.
<lain>
the ddr init might be in the CM3, I forget
<lain>
but yes, the management system is just the CM3 as best I can tell
Miyu has joined ##openfpga
hackkitten has quit [Ping timeout: 268 seconds]
<lain>
marvell's VSoC stuff (which includes the armada 8040) is really neat
<cyrozap>
Ok, that's in line with other aarch64 boards I've seen, but still kind of annoying :/
Miyu is now known as hackkitten
* lain
nods
<cyrozap>
I really just want a nice non-Intel/AMD system that doesn't cost $$$$ that I can use as a core router board that has WireGuard connections to each device on my home network (i.e., has accelerated crypto) and has enough CPU to do bufferbloat management stuff.
<lain>
yeah
<gruetzkopf>
how the *f* did intel manage to screw up the thunderbolt host side implementation so badly
<cyrozap>
Like, I _could_ use my Talos for that, but that would use literally 10 times the power _at least_.
<gruetzkopf>
especially as *their people* implemented proper pcie hotplug support
<cyrozap>
And my current router is a (mostly, since I haven't been able to get the U-boot sources from the OEM) blob-free WAP, and I don't want to decrease my freedom/security for a little speed boost.
<lain>
gruetzkopf: having seen the intel nda site, they uhhh have issues doing anything tbh. it seems like localized groups of engineers within intel have a clue, but the management structure is aggresively anti-communication and anti-productivity
<lain>
I am 99% sure the entire doc management system is a single person with a small pile of handcrafted vbscript
<cyrozap>
gruetzkopf, lain: Even without NDA access to Intel, it's clear to me as an outside observer that Intel has gotten waaaay too comfortable with their dominant market position, and after being that way for years, they've forgotten how to do anything right.
<lain>
agreed, it's rather unfortunate
<cyrozap>
"Galileo isn't a runaway success? Scrap it! Let's go buy a bunch of startups!"
<lain>
oh I loved Intel's approach to IoT: let's spray a bunch of products onto the market, be confused when people ask about long-term support / sourcing, and then scrap it because we don't understand how business works
<gruetzkopf>
i see absolutely no reason for anything out-of-band to happen here
<gruetzkopf>
the downstream hotplug events should have been forwarded via pcie
<cyrozap>
Intel is like the person who compulsively buys dumb things they don't need to make themselves feel like everything is ok and they're still on the up and up when it really isn't and they really aren't.
<lain>
XD
<cyrozap>
It's like freaking "Death of a Salesman"
<cyrozap>
And Intel is Willy Loman
<lain>
anyway I'm super excited for an arm laptop in a thinkpad chassis w/ 2x SFP+ cages, oodles of ECC DDR4, nvme drives, fpga for misc fuckery, yada yada
<gruetzkopf>
(like, the pcie bese spec explicitely forbids the behaviour thunderbolt shows)
<whitequark>
gruetzkopf: I think the reason here is that the firmware has to reserve IDs for hotplug devices
<whitequark>
and it might not know how to do that unless it knows there'll be Thunderbolt somewhere
<gruetzkopf>
yeah, sure
<gruetzkopf>
but that doesn't mean oob wiring should exist
<whitequark>
that's true
<whitequark>
the firmware could just use the PCI class..
<gruetzkopf>
i might grab one such card and poke at it
<whitequark>
I bet it's plugged into SMBus
<gruetzkopf>
(which is available on the pcie connector?)
<whitequark>
...
<whitequark>
right
<whitequark>
what the fuck?
<gruetzkopf>
exactly
<whitequark>
gruetzkopf: oh
<whitequark>
it's for displayport
<gruetzkopf>
those are on the outside
<whitequark>
yeah, they loop back to the thunderbolt card
<whitequark>
and the TBT_C connector has a few undocumented GPIOs
<whitequark>
that have "something" to do with displayport routing
<gruetzkopf>
i really want to know what their engineers took before working on it
<gruetzkopf>
it's not like displayport ALSO supports multistream and hotplug natively
<whitequark>
gruetzkopf: impressive, supermicro typically documents pinout of every single header
<whitequark>
but their motherboards with thunderbolt have no such description
<whitequark>
"The JTBT1 header is a general purpose I/O header for a Thunderbolt add-on card."
<gruetzkopf>
(where macOS is the one exception in mst support)
<whitequark>
I wonder if it's literally just GPIO and ACPI bitbangs the card.
<whitequark>
what I've seen of the design so far makes it pretty likely
<gruetzkopf>
i don't see any need for that at all..
<whitequark>
39:00.0 USB controller [0c03]: Intel Corporation DSL6340 USB 3.1 Controller [Alpine Ridge] [8086:15b5]
<whitequark>
1c.0 is the root port it's under
<whitequark>
gruetzkopf: anyway, in this mode the actual thunderbolt interface is sleeping
<whitequark>
by running an undocumented ACPI call, or poking the firmware through the intel-wmi-thunderbolt interface (which does a write that causes an SMM trap which sets a GPIO)
<whitequark>
I can make a Thunderbolt NHI interface to appear
<whitequark>
EC is also somehow involved
<gruetzkopf>
that's the native device to device packet mode?
<whitequark>
I don't actually understand Thunderbolt well because the whole goddamn thing is nigh undocumented
<whitequark>
but the Linux NHI driver is concerned with setting up the switch topology
<gruetzkopf>
what happens in the usb mode is fairly close what i had expected
<whitequark>
Thunderbolt is kind of like MPLS, you see
<whitequark>
you have endpoints and you can connect switches at those endpoints to make a path through the entire graph
<gruetzkopf>
yeah, they're not *actually* switching on the pcie layer
<whitequark>
what
<whitequark>
what do you mean
<gruetzkopf>
AFAIU they're encapsulating TLPs in their own frames and handle only those
<whitequark>
oh yeah something like that
<whitequark>
so that you can mux displayport into it
<gruetzkopf>
so they're not actually converting back to pcie, run through pcie switch, encapsulate again
<whitequark>
ok, so the Linux NHI driver configures two ring buffers, which I think are mostly used for commands
<whitequark>
and IPoTB
<gruetzkopf>
even though they tell the host that for enumeration purposes
<gruetzkopf>
(which again i'd have done differently)
<whitequark>
and I never got any further because uh
<whitequark>
because the Thunderbolt 3 to 2 adapter I have and the USB type-C PD controller can't agree on the alternate mode
<whitequark>
for unidentified reasons
<whitequark>
and I fucked up SPI_SSZ pin while reworking it and now I need a new one :(
<gruetzkopf>
SPI_SSZ sounds like TI
<whitequark>
but on the bright side I dumped the firmware, mapped almost every testpoint, found a TI configuration tool, ported it to Linux, mostly figured out the firmware format, and such
<whitequark>
uuuunfortunately the new adapter will also come with a thick metal shield
<whitequark>
i spent like half a hour with a dremel on *this* one
<whitequark>
i do not look forward to doing it again
<gruetzkopf>
how'd they get it in there in the first place
<whitequark>
it's spot welded in over 80 places
<whitequark>
and soldered to the board
<gruetzkopf>
way to go, fruit company
<whitequark>
well and then there's the white ABS glued shut
<gruetzkopf>
"does not support displays" wtf
<whitequark>
oh yeah
<whitequark>
which is weird
<gruetzkopf>
did they forget the DP wiring?
<whitequark>
because it doesn't actually have anything in the data path
<whitequark>
not even a redriver
<whitequark>
it just has an USB PD uC and a Thunderbolt power mux
<gruetzkopf>
wtf, fruit company
<whitequark>
well and a few voltage regulators
<whitequark>
fun fact
<whitequark>
every. single. IC. has Apple-proprietary markings.
<gruetzkopf>
"we didn't feel like you should be able to use your 5k$ displays anymore"
<gruetzkopf>
yeah, they're great with that
<gruetzkopf>
especially for type-c controllers
<whitequark>
but they didn't seem to realize that TI doesn't have more than one chip in VQFN20 package and that the firmware contains the PD uC name
<gruetzkopf>
they have at least two incompatible versions of the same type-c controller in their laptop
<whitequark>
yeah
<gruetzkopf>
like -B and -C
<whitequark>
it's TPS65983B
<whitequark>
and TPS65983A
<whitequark>
fun fact
<whitequark>
TI says that TPS65983B is an exact replacement for TPS65983A
<gruetzkopf>
afaik there's also a -C in laptops
<gruetzkopf>
custom marked
<whitequark>
I think -C is Apple-speak for TI -B
<whitequark>
moreover
<whitequark>
Apple's thunderbolt kext actually refuses to work with any devices with TPS65983A
<whitequark>
it's excluded via a PID blacklist
<gruetzkopf>
wtf
<whitequark>
now, I actually compared the datasheets of -A and -B
<whitequark>
they're essentially identical other than some layout and wording changes
<gruetzkopf>
maybe -a was cheaper by fruit tax amount?
<whitequark>
I feel like the *real* differences are under NDA
<whitequark>
because TI clearly distingushes these devices internally
<whitequark>
oh also
<whitequark>
"CC3211" is Apple-speak for TPS22981
<whitequark>
it's the only Thunderbolt IC in VQFN20
<whitequark>
and the pinout matches exactly
<gruetzkopf>
good to know
<whitequark>
sorry, CD3211
<whitequark>
whereas CD3215 is TPS65983
<whitequark>
sigh
<whitequark>
they even got the *FETs* with Apple-proprietary markings
<whitequark>
just how anal do you have to be to get Fairchild to do that
<whitequark>
MPFF3428
<whitequark>
ok wait that's an obscure boost
<whitequark>
FDMC02238
<whitequark>
is the FET
<gruetzkopf>
but why?!
<whitequark>
I dunno
Bike has joined ##openfpga
<gruetzkopf>
(which reminds me that i need to replace the HDMI port in my current laptop with a DP port)
<gruetzkopf>
because getting at PEG is fairly impossible with this board (too bad that "pull the complete bga footprint to the back of the board" died out)
Miyu has joined ##openfpga
<gruetzkopf>
(hm, i could get the next model up and go full crazy and add a PCIe switch between the dGPU and the CPU?)
<gruetzkopf>
that's only like 140 bodgewires
whitequark_web has joined ##openfpga
<whitequark_web>
gruetzkopf: you're nuts.
<gruetzkopf>
why?
<gruetzkopf>
the only thing i need to figure out for that is thermal budget :P
<whitequark_web>
no reason :p
<gruetzkopf>
(i'm still looking for sata-style diff-microcoax cables)
<whitequark_web>
hm
<whitequark_web>
sata is microcoax?
<whitequark_web>
why are they flat?
<whitequark_web>
oh
<gruetzkopf>
4 side by-side
<whitequark_web>
i get it
<whitequark_web>
so
<whitequark_web>
i fucked up my thunderbolt adapter
<whitequark_web>
lifted a bga pad accidentally
<whitequark_web>
and an important one too
<whitequark_web>
well i guess it's only like 50% important, it's SPI_SS
<whitequark_web>
and it can boot via CC_SBUn
<whitequark_web>
but anyway i drilled out the ViP
<whitequark_web>
exposed copper underneath
<whitequark_web>
couldn't get it to tin so i'm just going to have the chip reballed and soldered on
<whitequark_web>
worst case, i have to boot it via SBU
<gruetzkopf>
also: i'm not that good with electronics, it's only lack of respect for high-speed-differential stuff
<gruetzkopf>
if i had to know in advance that this works i'd nope out pretty quickly
<whitequark_web>
well for one you can solder 140 bodge wires
<whitequark_web>
i think the most i had was like 30
<whitequark_web>
and that was a nightmare
<whitequark_web>
and it wasn't bga
<whitequark_web>
or very fine pitch anyway
<whitequark_web>
i wonder if you can run pcie over barbed wire
<whitequark_web>
impedance match by using the appropriate distance in air
<pie__>
little antennas everywhere
<gruetzkopf>
don't make me try :P
<gruetzkopf>
(also, the system i'm currently with on has like 25k wire-connector solder joints and 15k individual wires hooking up lamps and buttons to relays..
<whitequark_web>
gruetzkopf: have you run pcie through any relays yet
<gruetzkopf>
surprisingly, no
whitequark_web has quit [Ping timeout: 252 seconds]
<gruetzkopf>
hmm. data exfiltration technique: ethernet frames over usb CC wire?
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
<cpresser>
azonenberg_work: you around? i could use a bitstream for the reworkctf
<azonenberg_work>
cpresser: i dont know if i ever wrote a grader firmware
<azonenberg_work>
my recollection is, i had started working on it when i found the pinout bug that made ~1/3 of the problems ungradeable
<azonenberg_work>
without switching to the 3s200a
<azonenberg_work>
(did i mention this wasnt quite ready for prime time? :P)
<cpresser>
yes, you did
<azonenberg_work>
but it would be pretty trivial to write for the stuff that is bonded out in the 3s50a
<cpresser>
i hoped some o the graders would work, so I wanted to test them
<azonenberg_work>
basically just toggle a slow squarewave down each pin and verify that it changes state correctly
<azonenberg_work>
and that it's no longer shorted to whatever it was / it does connect where it should
<cpresser>
i just dont want to setup a xilinx toolchain on my travel notebook
<azonenberg_work>
oh actually
<azonenberg_work>
i do have a partial firmware
<azonenberg_work>
gimme a sec to try compiling it
<azonenberg_work>
cpresser: ok so i have the bitstream
<azonenberg_work>
got an email address i can send it to? i dont have easy access to my web hosting from here
<cpresser>
c@rstenpresser.de will do
<cpresser>
thank you very much for your effort!
<azonenberg_work>
Looks like levels 7, 10, 11, and 16 are ungradeable now due to the "some pins are NC in the 3s50a" bug
<azonenberg_work>
this is in addition to the cosmetic fixes on stuff like soldermask and silkscreen that are obviously not machine gradeable :p
<cpresser>
I did silkscreen and soldermask, and they look horrible :)
<whitequark>
gruetzkopf: ahahaha it works
<whitequark>
it actually works
<whitequark>
after reballing and soldering
<cpresser>
right now other people are doing some challenges, I am just tutoring/helping.
<azonenberg_work>
:)
<azonenberg_work>
pix or it didnt happen
<cpresser>
twitter #reworkctf
<cpresser>
i am up to level 11 myself, will do the harder challenges later today or at home. for now, camp-visitors will use the tools
<cpresser>
we really enjoy it. so again, thank you very much for creating this!
<whitequark>
azonenberg_work: so I didn't reball and solder it myself because I didn't have a stencil or balls, and when I went to the electronics market to get them I decided to just skip the risk of ruining a fairly expensive device and let them do it
<whitequark>
but I *did* drill out the ViP and make sure the layer underneath is exposed and clean
<whitequark>
and I did this without a fancy microscope or $2000 drill press :P :P
<gruetzkopf>
you're talking about the fruit companies TB3->TB2 adapter?
<whitequark>
I think I'd reball it just fine, but I was afraid of accidentally moving any of the 0201 components around, I always have issues with that when reworking modern high-density PCBs
<whitequark>
a part of it is that I don't have any small nozzle for my hot air gun
<whitequark>
but another part is that the meds I'm on cause serious hand tremors
<whitequark>
gruetzkopf: yeah
<whitequark>
enumerates, which wouldn't happen if there was no contact at the torn off pad
<whitequark>
or at least it would not enumerate with the factory descriptors
<gruetzkopf>
nice
<whitequark>
indeed
<whitequark>
saves me quite a bit of money too
<gruetzkopf>
(apparently the apple TB2->GigE adapter has pcie on the cable (TB ic in the TB plug, nic in the eth plug
<whitequark>
yeah
<whitequark>
seen that
<whitequark>
I would actually use that for eGPU... if not for the fact that I only have TB3 on my laptop
<whitequark>
so I'm back to square one lol
<gruetzkopf>
(but as i have zero TB hardware..)
<whitequark>
KEEP IT THAT WAY
<whitequark>
CURSED PIECES OF SHIT
<gruetzkopf>
looks interesting enough :P
<whitequark>
well I guess you can get the adapter I have :P :P
<whitequark>
I think it's a nice cheap USB PD devboard
<whitequark>
... assuming you can actually cut it out of its metal prison, anyway
<gruetzkopf>
(but yeah, i'd rather have oculink ports)
<whitequark>
wtf is oculink
<gruetzkopf>
the newer pcie cabling spec
<whitequark>
oh
<whitequark>
OCuLink
<gruetzkopf>
with less ridiculous connectors
<whitequark>
ahaha yet another connector
<whitequark>
couldn't they just like
<whitequark>
add a PCIe alternate mode for USB-C
<gruetzkopf>
that's a thing
<whitequark>
wtf
<gruetzkopf>
but not for x4 and x8
<whitequark>
why is Thunderbolt a thing then
<gruetzkopf>
no clue
<gruetzkopf>
TB framing is mostly a thing because of the (practically nonexistant) optics support
<gruetzkopf>
it was supposed to be *the* big consumer optical interface
<gruetzkopf>
(i've looked some more, i wouldn't even need a pcie switch in the next laptop up, i could simply set the PEG port to 8x+x4+x4 again and steal half the lanes)
<whitequark>
ugh
<gruetzkopf>
quite easy, only neccesitates moving 2 resistors and like 32 capacitors
<whitequark>
why do you need caps anyway
<gruetzkopf>
pcie is capacitively coupled?
<whitequark>
oh i mean
<whitequark>
why aren't they there already
<gruetzkopf>
they're there
<gruetzkopf>
i just need to move half of them and remove the other
<gruetzkopf>
the caps are the ideal place to get at the lane in question
<whitequark>
ohhh
<whitequark>
moving
<whitequark>
right
<gruetzkopf>
oh, they're quite cheap (writes on buy-next-month list)
<whitequark>
azonenberg_work: anyway do i get a honorary #reworkctf mention :P :P
<gruetzkopf>
(i mean, it's quite easy to test if this is viable, "simply" remove all the caps for the upper 8 lanes and restrap the CPU for bifurcation
<gruetzkopf>
i know that nvidia mobile GPUs work at x1 link width, don't know if they support x8
<whitequark>
gruetzkopf: i thought any pci-e device would start up with any link width
<gruetzkopf>
in practice, most do
<gruetzkopf>
only x1 and max width are mandantory iirc