futarisIRCcloud has quit [Quit: Connection closed for inactivity]
aquijoule__ has joined ##openfpga
aquijoule_ has quit [Ping timeout: 265 seconds]
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 265 seconds]
X-Scale` is now known as X-Scale
Degi_ has joined ##openfpga
Degi has quit [Ping timeout: 240 seconds]
Degi_ is now known as Degi
PyroPeter_ has joined ##openfpga
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter_ is now known as PyroPeter
futarisIRCcloud has joined ##openfpga
tokomak has joined ##openfpga
_whitelogger has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
jeanthom has joined ##openfpga
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
aquijoule__ has quit [Ping timeout: 240 seconds]
tokomak has quit [Ping timeout: 264 seconds]
mumptai has joined ##openfpga
mumptai has quit [Remote host closed the connection]
futarisIRCcloud has joined ##openfpga
mumptai has joined ##openfpga
Bike has joined ##openfpga
<balrog>
mwk: I'm intrigued by whatever you're doing with the ancient xilinx tools
<mwk>
oh just looking around
<mwk>
mostly to see if the old parts are similar enough to new parts to be covered by the same RE project
<balrog>
a while back I poked at some older xilinx stuff, but I'm not quite remembering all the details at this point. Is there a specific RE project yet (like there's #prjmistral for altera)?
<mwk>
an early one
<balrog>
how early? is there an IRC channel or group for it yet?
<mwk>
no
<balrog>
alright!
<mwk>
but fyi if you're looking at the very early stuff
<mwk>
like xc2000-xc5200
<mwk>
the toolchain makes it... very unwieldy to make a fuzzer
<mwk>
but possible
<mwk>
obtaining the geometry and routing information for the parts is the main pain point
<mwk>
once you do that, the rest can be scripted
blazra has quit [Quit: Idle for 30+ days]
ym has joined ##openfpga
genii has joined ##openfpga
<balrog>
mwk: even the data in the 1993 databook looks rather sparse
<balrog>
iirc one of the toolchains had a graphical editor though?
<balrog>
hmm, wonder if the decaps can help with some of that info
<mwk>
oh there is a graphical editor
<mwk>
and it's perfectly doable to extract everything from it, but very tedious
<balrog>
seems like ken shirriff did some of that work for us
<balrog>
(using decaps)
<mwk>
no
<mwk>
the problem with decaps is that they, by necessity, cover only a single part
<mwk>
and there are craploads of parts
<balrog>
yeah
<balrog>
> While the bitstream directly maps onto the hardware layout, the bitstream file (.RBT) does have a small amount of formatting, shown below.
<balrog>
huh that reminds me of the coolrunner-ii bitstream files which also had some formatting iirc
<mwk>
coolrunner-ii bitstream files are a really strange beast with the "virtual addressing"
<balrog>
ahh yeah, digshadow had done some RE/fuzzing on these a few years back
<balrog>
(I forgot all about it :()
<balrog>
that sort of virtual addressing is unusual?
<mwk>
very unusual
<mwk>
and basically completely pointless
<mwk>
like, the point of a bitstream is that you have something that you can just throw at the device
<mwk>
and the device doesn't care about any concept of virtual addresses
<balrog>
yeah
<balrog>
extra logic in the chip for no good reason
<mwk>
no
<mwk>
extra logic in the *programmer* for no good reason
<mwk>
the chip doesn't have any concept of virtual addresses, it only understands physical ones
<mwk>
so whatever software translates the bitstream file to JTAG commands has to perform address translation, which is bullshit
<balrog>
ohhhh, ewww.
<mwk>
I mean, the bitstream generation tools for coolrunner ii also have the option of making a ieee 1532 file which does use physical addresses and avoids the whole mess
<balrog>
then why did they even bother?
<mwk>
*shrug*
<balrog>
my guess is that someone at xilinx thought it was a good idea at the time
<balrog>
heh
richbridger has joined ##openfpga
<digshadow>
balrog: azonenberg et al was more closely involved but yeah
<balrog>
digshadow: aaah! ok
<digshadow>
mwk: FWIW I created an xc2000 fuzzer PoC but didn't take it too far
<balrog>
mwk: which early xilinx chips are you trying to target?
<mwk>
balrog: all of them
<balrog>
yeah, so it's a mess because they all have different parameters and routing fabric is complicated
<balrog>
someone in here was trying to make something for PSoC, which has some bitstream documentation but also uses an extremely complex routing fabric
emeb_mac has joined ##openfpga
<azonenberg>
mwk: the 1532 files were physically addressed?
<azonenberg>
i never looked at those
<mwk>
yes
<mwk>
I mean, they have to be
<azonenberg>
i assumed they werent actually fully 1532 compliant and needed address twiddling too
<azonenberg>
or something
<azonenberg>
also to be clear the generated SVFs do have actual jtag instructions and physically addressed bitstream data
<mwk>
SVF matches the 1532 files
<azonenberg>
jed, however, is supposed to be a physically addressed format
<azonenberg>
and the coolrunner jeds are not
<mwk>
huh, jed is an actual standard?
<azonenberg>
yes
<azonenberg>
jesd3c iirc?
<azonenberg>
been a while
<azonenberg>
but it is a jedec standard hence the name
<mwk>
fair enough
<azonenberg>
balrog: and tl;dr the coolrunner jed files are nicely logically laid out which made them super easy as a first RE target
<azonenberg>
they actually had ascii text comments describing the behavior of different blocks
<azonenberg>
e.g. "block 1 PLA" etc
<azonenberg>
actually i think even pla and and or were separate
<azonenberg>
the only part that took serious work to figure out was the routing matrix
<azonenberg>
i knew what bits controlled it but not what they did
<azonenberg>
the macrocell bits were all 1:1 with muxes in the datasheet
<azonenberg>
and the PLA was all one-hot
ym has quit [Ping timeout: 240 seconds]
keesj has quit [Ping timeout: 246 seconds]
<kc8apf>
jesd3c is a "standard"
<kc8apf>
it's slightly better than BLIF but not much