<kc8apf>
is there some secret for creating a generated clock in Vivado? "Edit Timing Constraints" window will let me pick pin that have the right-ish names but then fails to find those same pins during synthesis
<pie_>
man i want to write some project proposals for some stuff but theres so much that still needs to ripen first so eh...
unixb0y has quit [Ping timeout: 240 seconds]
unixb0y has joined ##openfpga
<kc8apf>
Argh! Why doesn't vivado realize it could meet timing constraints by avoiding a LUT with a few logic equivalences
<pie_>
kc8apf, D:
m_w_ has quit [Quit: Leaving]
digshadow has quit [Ping timeout: 264 seconds]
genii has quit [Remote host closed the connection]
digshadow has joined ##openfpga
rohitksingh_work has joined ##openfpga
soylentyellow has joined ##openfpga
soylentyellow has quit [Max SendQ exceeded]
soylentyellow has joined ##openfpga
soylentyellow has quit [Max SendQ exceeded]
soylentyellow has joined ##openfpga
soylentyellow has quit [Max SendQ exceeded]
soylentyellow has joined ##openfpga
Zorix has quit [Ping timeout: 245 seconds]
Zorix has joined ##openfpga
<awygle>
okay, kicad users? how do i ... just... navigate around the schematic page?
<awygle>
i've used altium for something like 6 years and i just want to right click to drag...
<rqou>
wait what
<rqou>
did you actually pay for it?
<rqou>
(altium)
<awygle>
rqou: i used it at work, and i paid for CircuitStudio which is similar but with gratuitous annoyances added for 1/7th the cost
<whitequark>
awygle: middle button drag iirc
<pie_>
try all the buttons
<pie_>
fuck up your config
<pie_>
reinstall
<pie_>
try again
<awygle>
whitequark: thanks. unfortunately i am, for reasons best described as "where the fuck is my mouse", currently using a trackpad.
Bike has quit [Quit: Lost terminal]
<azonenberg>
awygle: i usually just use the scoll wheel
<azonenberg>
scroll out, mouse to the middle of where i want to go, scroll in
<azonenberg>
i know there's an alternative but i dont know what it is
<azonenberg>
i do know kicad in general requires a wheel mouse
<awygle>
azonenberg: that is what i'm currently doing and i hate it so much l ol
<azonenberg>
why?
<awygle>
i better buy a new mouse posthaste
<azonenberg>
oh without a mouse then you have problems
<eduardo__>
rqou: what do you have to do wiht nRF51? We use it in a product. You just hack on it?
<rqou>
yeah, i was just wondering
<rqou>
the nrf51 has a known exploit to bypass code readout protection
rohitksingh_work has quit [Ping timeout: 265 seconds]
rohitksingh_work has joined ##openfpga
rqou has quit [Remote host closed the connection]
rqou has joined ##openfpga
pie_ has quit [Ping timeout: 264 seconds]
pie_ has joined ##openfpga
SpaceCoaster has quit [Ping timeout: 245 seconds]
SpaceCoaster has joined ##openfpga
<rqou>
hey azonenberg
<rqou>
azonenberg: did you ever look at my master_fixed branch that i pushed into your yosys repo? i tried to clean up the crazy messy history, and it was up-to-date with upstream master before you pushed your recent merges
pie_ has quit [Ping timeout: 240 seconds]
<azonenberg>
rqou: no i didnt get a chance to
<azonenberg>
i'm going to be crazy busy until a month or so after the move i think
<rqou>
move faster :P
<azonenberg>
I pulled down sheetrock in a closet and installed a ceiling light today
<azonenberg>
(after work, only had ~2 hours or so before it got too late to do noisy construction)
<rqou>
why too late?
<rqou>
neighbors?
<azonenberg>
yeah, there are houses not too far away and we figure they wouldn't enjoy the sounds of impact drivers and hammers at midnight
<azonenberg>
So we try to stop work by 2100
<azonenberg>
sometimes we go a little later to do quiet stuff like organizing tools, installing wire nuts, etc
<rqou>
wow, actually considerate :P
<azonenberg>
That and, i have other stuff to do at home once i get back
<azonenberg>
We shower after construction rather than in the morning to decon after getting all covered in smoke residue and dirt etc
<azonenberg>
any day we do demo the house reeks
<rqou>
not a giant "nobody gives a damn" slumlord apartment complex :P :P
<azonenberg>
then it takes several days for the hepa filter air cleaners to get the particle counts down to the point the place smells ok
<rqou>
hey azonenberg
<rqou>
you need to update the submodules in jtaghal-cmake
<azonenberg>
poke awygle, he pretty much maintains that
<azonenberg>
anyawy I'm quite looking forward to being done with demo in a few more days
<azonenberg>
We have to remove the sheetrock in the hallway closet, the dining room walls, the hallway/dining room/living room ceilings
<rqou>
i still don't get why you like OOP so much
<rqou>
or maybe i just hate OOP a lot
<azonenberg>
Insulation in the attic over the living room and dining room,, and one stray piece of wall insulation that was hiding in a closet that got missed earlier
<azonenberg>
Once that's done we're going to do a full top to bottom clean and scrub of every stud, joist, and inch of floor
<rqou>
btw, is the scope of jtaghal supposed to replace openocd?
<azonenberg>
vacuuming everything then wiping stuff down with wet cloths etc to remove smoke residue
<azonenberg>
The goal is to be a permissively licensed openocd alternative, yes
<azonenberg>
although my primary focus has been on fpgas vs mcus
<rqou>
also, is there a tutorial on how to use it? :P
<azonenberg>
Nope, feel free to write one
<rqou>
can i flash a coolrunner2 yet?
<azonenberg>
the 32a, yes
<azonenberg>
i havent implemented the remappings for the other parts
<azonenberg>
i didnt want to depend on the ise rom files
xdeller__ has quit [Quit: Leaving]
<azonenberg>
so i actually re'd the mapping and created a procedural version that reflects the die structure
<rqou>
yeah, my lib also has a procedural version
<azonenberg>
as a side benefit it's faster than fscanf'ing the file :D
xdeller has joined ##openfpga
<rqou>
but i need to fix up my ffi stuff
<azonenberg>
i tested
<azonenberg>
(not the reason i did it, but convenient)
<azonenberg>
Re documentation, most of these tools are things i wrote to solve a problem i had RIGHT NOW
<azonenberg>
and needed solved immediately
<rqou>
ok, as a first order approximation, what to i have to run to get something to happen?
<azonenberg>
I commented it enough to be maintainable
<azonenberg>
But there's no end user docs
<rqou>
there's jtagd, jtagclient, and "svfdumper" which seems to do something completely unrelated
<rqou>
why is there a client-server architecture?
<azonenberg>
Because the intended use case was to have a hardware server somewhere in the lab, which may not even be on a physical PC (starshipraider will have one in RTL)
<azonenberg>
plugged into your DUT
<azonenberg>
then you run jtagclient to talk to it
<azonenberg>
i routinely have jtagd's on separate machines than jtagclient
<rqou>
so if i plug in the board you gave me, it should be able to detect something?
<azonenberg>
I may eventually implement a standalone jtagclient mode where it self-hosts an internal jtagd essentially (withotu the socket layer in between)
<azonenberg>
but it was never a priority
<azonenberg>
Yes
<azonenberg>
run jtagd --list to see what it found
<azonenberg>
then jtagd --api [ftdi|digilent] --serial foo
<azonenberg>
by default it'll pick a free port number, you can do --port 1234 if you want to bind to something in particular
<azonenberg>
If you dont have udev rules for the devices you may have to chown the /dev/bus/usb entries to yourself
<rqou>
er, neither the digilent nor ftdi apis are supported?
<azonenberg>
How did you install them?
<rqou>
"cmake .."
<azonenberg>
no
<azonenberg>
i meant the digilent and ftdi headers/libs
<azonenberg>
the cmake build just looks for what you have on your system
<rqou>
er, "sudo apt-get install libftdi-dev"
<azonenberg>
So first off i dont know what awygle did in the cmake stuff
<azonenberg>
in splash i do some lib finding stuff then define HAVE_FTDI or HAVE_DJTG
<azonenberg>
i dont know if he implemented that side or just went "oh it compiles we're good"
<azonenberg>
Second, libftdi is the buggy f/oss library that is almost, but not quite, api compatible with the binary blob libftd2xx
<azonenberg>
Which is what i target
<azonenberg>
i started with libftdi, it didn't work reliably
<azonenberg>
then i switched to libftd2xx and it mostly works
<azonenberg>
the two can be installed side by side
<azonenberg>
So you'll want to grab the blob package and install that
<rqou>
have you tried, you know, fixing libftdi? :P
<azonenberg>
I'm willing to accept PRs
<rqou>
you're such a weirdo, using the blob lib
<azonenberg>
But i have no time to do it myself
<azonenberg>
Priority #1: get my job done
<azonenberg>
priority #2: use f/oss to do so, to the extent practical
<azonenberg>
if 2 interferes with 1, it loses
<azonenberg>
I'll gladly accept a PR to support both libftdi and libftd2xx (i dont want to rule out use of the blob entirely but the two should be close enough in api that you can ifdef a few things)
<rqou>
what is broken in libftdi? do you remember?
<rqou>
any good way to test?
<azonenberg>
i remember the mpsse being either unimplemented, or nonfunctional
<azonenberg>
this was back in circa 2013 so they may have fixed it since
<rqou>
that's definitely not right
<rqou>
not even for 2013
<rqou>
i had definitely used it
<azonenberg>
i wrote this code when working on my thesis, it might have been as early as '11
<azonenberg>
i just remember the most basic things being completely nonfunctional to the point that pins didnt even toggle
<azonenberg>
then the blob just worked out of the box
<azonenberg>
So i stopped trying
<azonenberg>
But if you dont mind using the blob, it works
<azonenberg>
(again, if awygle didn't implement lib detection you might have to patch the cmake cflags to define HAVE_FTD2XX manually)
<rqou>
this is bullshit :P
<azonenberg>
If modern libftdi works out of the box, i'll take it
<azonenberg>
I just dont have time to port things
<azonenberg>
my focus right now is on writing code that solves problems i have at $dayjob or for $sidegig
<azonenberg>
i dont have time for anything else
<rqou>
what "level of abstraction" is the jtagd wire protocol?
<azonenberg>
So, jtaghal has three levels of abstraction depending on how "smart" the adapter is
<azonenberg>
Low level: raw TDI/TDO/TMS bits
<azonenberg>
This is f.ex what the MPSSE provides
<azonenberg>
Mid level: State transitions, TMS data is generated for you
<azonenberg>
High level: Register level stuff, includes primitives to do things like "walk the chain and see what we have" or "get the ID code of the Nth device on the chain" or "set the IR for the Nth device to 0xdeadbeef"
<azonenberg>
(some of the code doesn't correctly implement padding for multi-device chains, but the indexes are there in the API so it will be a drop-in upgrade if/when i have a need for it)
<azonenberg>
The jtaghal wire protocol provides the low and mid level APIs, as well as access to a GPIO interface if the jtag dongle has one
<azonenberg>
the high level API is done clientside in the JtagInterface class, although i'm not opposed to adding features to do that server side down the road
<azonenberg>
Right now the protocol is raw packed binary 8-bit opcode + arguments
<azonenberg>
i'm going to switch to protobuf in the near future once my hardware protobuf library is done
<azonenberg>
This will be a transparent change at the C++ API level
<rqou>
oh wtf ftd2xx is very windows-contaminated
<azonenberg>
Yes, they have a WinTypes.h header to bring in windows types for their use
<rqou>
what is wrong with them?
<azonenberg>
I wish i knew
<azonenberg>
i dont like ftdi stuff, and if i had any choice in the matter i'd stop using their products (not because of corporate ethics or their bricking fakes, i only use legit parts - but the stack is just buggy and cpu-hungry)
<azonenberg>
on a beaglebone, having half a dozen ftd2xx handles open saturates the cpu
<azonenberg>
with no data being sent, just from all the threads polling
<azonenberg>
i tried to use a beaglebone as a jtaghal hardware server and it fell flat on its face
<rqou>
ok, jtagd detects
<rqou>
how do i use jtagclient?
<azonenberg>
to start, jtagclient --server localhost --port N
<azonenberg>
it should walk the chain and see what you have there
<azonenberg>
Oh, i thought i had that defaulting to localhost? could be wrong
pie_ has joined ##openfpga
<azonenberg>
port definitely has to be specified
<rqou>
it just prints the banner unless i specify it
<azonenberg>
ah ok
<azonenberg>
i'm used to having so many jtagd's running that i always specify
<rqou>
fortunately, ::1 works
<rqou>
knowing you i'm not surprised :P
<azonenberg>
and yes everything is fully ipv6 enabled
<azonenberg>
Does it work?
<azonenberg>
also you can add --verbose or --debug to see lots more details
<azonenberg>
same logtools framework as gp4par
<azonenberg>
smarter defaults are certainly an option but keep in mind the original use case of these tools was a unit test farm with about 15 devkits in it
<rqou>
it doesn't because the jumpers on your board are confusing as f*ck :P
<azonenberg>
It's just muxing chain inputs and outputs
<azonenberg>
let me pull up the board and see
<azonenberg>
Sooo if memory serves me right, to target the 32a
<azonenberg>
You want to have JTAGx_SRC[2:0], which are vertical dip switch bank, set to TGT0 which is 3'b000
<azonenberg>
Then GTG0_SRC[2:0], which are the horizontal switch bank 6-8, set to JTAGx which is 3'b100 or 3'b101
<azonenberg>
i forget if JTAG0 or JTAG1 is the ftdi or the adapter
<azonenberg>
You also want to have the chips that are NOT being used set to go somewhere else
<azonenberg>
When configured correctly, the target[3:1] chain LEDs should be showing red
<azonenberg>
and target0 chain should be green or yellow, depending on which jtag source is enabled
<rqou>
yeah, i need the schematic again i think
<azonenberg>
do you have it?
<rqou>
the problem is that a whole bunch of stuff is inverted
<rqou>
you sent me a link, but i can't find it right now
<azonenberg>
sec...
<rqou>
ah found it
<azonenberg>
ok so jtag0 is the ftdi
<azonenberg>
Your jumper settings for the vertical dip switch should be, left to right... {3'b000, 3'b001, 2'bx}
<azonenberg>
For the left horizontal dip switch: { 1'bx, 3'b101, 1'bx, 3'b100}
<azonenberg>
For the right horizontal dip switch: { 1'bx, 3'b101, 1'bx, 3'b101 }
<azonenberg>
actually, the 3'b101's should be 3'b111
<azonenberg>
So vertical: 000001xx
<azonenberg>
left: x111x100
<azonenberg>
right: x111x111
<azonenberg>
Expected result: TARGET0 CHAIN led green, TARGET[3:1] CHAIN led red
<azonenberg>
rqou: does that jive with what you're seeing?
<rqou>
no, i get the opposite
<rqou>
target0 is green and target1-3 are red
<azonenberg>
that's what we want
<rqou>
hmm
<azonenberg>
does it detect now?
<rqou>
i get that the scan chain has 0 devices (rather than being stuck)
<azonenberg>
0 devices? interesting
<azonenberg>
let me double check
<azonenberg>
JTAG0_SRC is jumpers 1-3 on the vertical
<rqou>
ok, 001000xx on the vertical works
<azonenberg>
oh you fixed it?
<azonenberg>
wait, 001 for jtag0_src?
<azonenberg>
thats the 64a
<rqou>
wtf
<rqou>
it detects the 32a
<azonenberg>
let me double check the constraints or something
<azonenberg>
sec
<rqou>
all 0 on that one works too
<rqou>
also, at this point i'm pretty sure there's a logic error in the mux that can lead to bus fights
<azonenberg>
ooook here we go
<rqou>
i noticed the vreg getting warm and the shitty psu that i use making more fan noise
<azonenberg>
DERP
<azonenberg>
The vertical dip switch
<azonenberg>
Where is switch 1
<azonenberg>
bottom or top?
<azonenberg>
(as seen with the majority of the text upright)
<azonenberg>
Switch 1 should be at the bottom, the board i have in my lab was assembled with the dip switch rotated 180 deg
<azonenberg>
if yours is the same, the settings on the vertical should be 000001xx from bottom to top
<rqou>
yeah, this one too
<azonenberg>
Ok so that makes sense
<azonenberg>
Does that dip switch setting work?
<azonenberg>
also i dont see how the mux could possibly bus fight because it's all boolean logic and every pin is unidirectional
<rqou>
idk either
<rqou>
that's just what i observed
<rqou>
wait, are the xx bits near the bottom or the top?
<azonenberg>
honestly the ftdi is probably the most power hungry part of that board
<azonenberg>
xx are at top
<azonenberg>
jtag0_src[2:0] are the bottom to third-from-bottom switches respectively
<rqou>
also, i definitely observed a warmer-than-usual LDO
<rqou>
so something bad happens sometimes
<rqou>
maybe it's related to the gpio mux
<azonenberg>
except i have the firmware source in front of me
<azonenberg>
and all of the gpio pins are tristated all the time
<azonenberg>
:p
<azonenberg>
i never implemented that part
<rqou>
hmm, idk
<azonenberg>
So, does the 32a work now?
<azonenberg>
also i think this may be a new record for longest time between pcb assembly and an errata being discovered
<azonenberg>
for me
<azonenberg>
lol
<azonenberg>
although i probably knew about it back in 2014 and just forgot
<rqou>
yes, i can get all of them except the 64a to work
<rqou>
i was having this issue before too
<azonenberg>
its possible there was a solder defect or something on the 64a, but we can look at the board design and see if there's a bug
<azonenberg>
In general the way the mux works is
<azonenberg>
you have to have one and only one sink attached to each source
<azonenberg>
i.e. having two chips connected to one chip's output will just make the whole chain shut down since it recognizes you asked for nonsense
<azonenberg>
3'b111 is the null source
<azonenberg>
So you should use that to blackhole the unused jtag1 port as well as inputs of any chip you arent using
<azonenberg>
so the 32a should have input to null if you want to use the 64a
<rqou>
"Bypassing extra devices not yet supported!"
<rqou>
thanks
<azonenberg>
yes, i never implemented multi-device chains
<azonenberg>
it should detect them
<azonenberg>
but it cant program them
<azonenberg>
(the nice thing about this board is you can put any chip in a chain by itself)
<rqou>
right, but all the "xyz is backwards" combined with unclear labels means that every time i pick this up after a while i forget how it's supposed to work
<azonenberg>
welp, blame my 4-years-younger self for not fixing the dip switch
<azonenberg>
rqou: what else is backwards about it?
<azonenberg>
nothing is active low or anything funny
<azonenberg>
it's just a series of muxes and you specify the input to each
<azonenberg>
tgt3_src means the input to target 3's jtag
<azonenberg>
then just right of the open hardware logo i have a table of which mux input is fed from where
<azonenberg>
with 111 being the undocumented "null" source
<rqou>
the problem is that various "conflict" states also lead to outputs indistinguishable from "not in chain"
<azonenberg>
Because the mux detects conflicts and removes everything in conflict from the chain
<azonenberg>
green = in chain 0
<azonenberg>
(ftdi)
<azonenberg>
yellow = in chain 1 (2x7 header at top)
<azonenberg>
red = not in either
<rqou>
btw debugging the 64a issue, i get no output whatsoever on TARGET1_TDI
<rqou>
tms and tck are ok
<rqou>
is it possible i have an old mux bitstream?
<azonenberg>
i'd be more inclined to suspect a bad solder joint
<rqou>
i probed straight on pin 1 of the mux cpld
<azonenberg>
sec...
<azonenberg>
pin 1 is indeed target1_tdi and the constraint file looks fine
<azonenberg>
i flashed the other two boards after i brought up the first
<azonenberg>
So we all have the same one
<azonenberg>
if there is a bug it's in the firmware i have too
<azonenberg>
and i dont have my board in front of me
<rqou>
well, somehow on my board the 64a just doesn't work
<rqou>
the other three are ok
<rqou>
idk how
<azonenberg>
yeah i'm really confused as to how that could be
<azonenberg>
you have the bitstream, maybe try replicating in simulation with your exact mux settings?
<rqou>
eh, later
<azonenberg>
just feed a squarewave into jtag0_tdi
<rqou>
that requires a whole bunch of setting up
<azonenberg>
and see what happens
<rqou>
also, have i mentioned how much of a _HUGE_ pain it is to work with a ton of submodules?
<rqou>
i have to individually go and fork each one, go in to the subdir, mess with git remotes, and then finally i can push
<rqou>
and then after that i have to make multiple PRs too
<azonenberg>
it would be nice if git handled that better
<rqou>
github makes things even worse
<openfpga-bot>
[jtaghal] rqou opened pull request #2: Properly link libftd2xx if available (master...master) https://git.io/vxcg7
<rqou>
another complaint: adding a new jtag adapter requires modifying way too much boilerplate
<azonenberg>
how would you suggest improving it? it seems quite simple
<azonenberg>
you add a new JtagInterface-derived class
<azonenberg>
and basically every function you override is hardware specific
<rqou>
i need to modify the global .h, the cmakelist, and the jtagd args
<rqou>
all of this is boilerplate
<azonenberg>
So the jtagd args part i agree could be easily improveable
<azonenberg>
the first two are pretty standard C++ though
<azonenberg>
i dont see how to improve on that without using a language that has modules or something
<azonenberg>
and has things simply exist by virtue of being in the source directory
<rqou>
yosys somehow has a way to load plugins without needing all of that?
<rqou>
also, wtf how come ftd2xx can fail at getting the version?
<azonenberg>
lol good question, it may never fail but they always return success? the api docs talk about a retur ncode i guess
<azonenberg>
anyway, the way i'd improve on things would be
<azonenberg>
some kind of global variable in the file that registers the class upon being constructed
<azonenberg>
or something
<azonenberg>
in general, adding new adapters has been such a rare thing i never bothered to optimize
<azonenberg>
i added ftdi and digilent and that encompassed everything i had in the lab
<azonenberg>
then everything else was socket based
<awygle>
It's pretty easy to do "grab all cpp files in this directory" in cmake I just didn't because it has other problems
<awygle>
Github is the main problem with submodules imo
<azonenberg>
well it's more, submodule forking is a pain in general
<azonenberg>
i dont know a better alternative though?
<azonenberg>
this is something i dont deal with much since i'm used to being the sole dev on these projects
<awygle>
Did I fuck up the cmake wrapper or was it library issues, rqou?
<azonenberg>
and working on master in the actual repo
<awygle>
azonenberg: forking == github
<rqou>
awygle: there are indeed bugs, i opened some PRs
<azonenberg>
awygle: you can make a fork of a repository without using github
<azonenberg>
what i meant was, trying to sync your own in-house version of a project with an external/public/upstream
<azonenberg>
when using submodules
<azonenberg>
is a bit painful
<awygle>
azonenberg: eh. Gitlab et al same thing. Raw git as e.g. Torvalds uses it has no such concept which is why everything sucks
<azonenberg>
i dont understand what you mean
<azonenberg>
i can clone the public repo, then push to my own private master
<azonenberg>
and continue doing so
<azonenberg>
that's a fork no matter where i host that master
<azonenberg>
it could be a file:/// for all i care
<awygle>
rqou: cool, will merge tomorrow (azonenberg correctly assessed the level of effort I put into the conversion)
<rqou>
wtf, there's a libftdi and a libftdi1?!
<azonenberg>
rqou: lol is libftdi the 0.x version?
<rqou>
i have no idea
<azonenberg>
(i've seen some libs that do that)
<awygle>
azonenberg: yes but if you're doing "git format-patch" iirc submodules actually work pretty ok
<azonenberg>
awygle: oh, you mean actually emailing patches around?
<awygle>
It's the whole "fork, PR, merge request, permissions" thing that makes it terrible (again, iirc)
<azonenberg>
i was talking about actually having a git server somewhere that you push changes to, separate from upstream
<azonenberg>
which i consider to be a fork
<azonenberg>
a PR in that model is simply an email saying "hey, my changes are at http://example.com/jtaghal.git, come grab them"
<awygle>
Note that I hate the format-patch model, but the fact that the Git maintainer uses it is useful to keep in mind when complaining about git
<rqou>
btw azonenberg the programming model you've used for jtag adapters seems pretty inefficient for libftdi
<rqou>
libftdi needs a global-ish context that there's no good place to allocate because of all the static methods
<azonenberg>
i've never tried having >1 adapter open in one process
<azonenberg>
typically you'd have one adapter per jtagd instance then just open sockets to those as needed
<azonenberg>
now that i think about it, that may have been one of the reasons i migrated away from it?
<rqou>
oh wtf
<rqou>
the comments in your code imply that it was originally using libftdi
<azonenberg>
Yes it was
<azonenberg>
i refactored it to use ftd2xx because it didnt work
<azonenberg>
i just dont remember exactly why i had the trouble
<azonenberg>
With that, it's 3 in the morning and i just fixed the bug i was hunting
<azonenberg>
Bedtime
pie_ has quit [Ping timeout: 256 seconds]
pie_ has joined ##openfpga
FabM has quit [Quit: ChatZilla 0.9.93 [Firefox 52.5.0/20171114221957]]
<rqou>
azonenberg: libftdi works for me
<openfpga-bot>
[jtaghal-apps] rqou opened pull request #1: Add support for using libftdi (master...libftdi) https://git.io/vxcKA
<openfpga-bot>
[jtaghal] rqou opened pull request #3: Libftdi (master...libftdi) https://git.io/vxc6v
<openfpga-bot>
[jtaghal-cmake] rqou opened pull request #2: Libftdi (master...libftdi) https://git.io/vxc6T
<rqou>
azonenberg: ^^^ do you see this? this is bullshit :P
<rqou>
this is why submodules suck
thallia has quit [Ping timeout: 240 seconds]
thallia has joined ##openfpga
eduardo_ has joined ##openfpga
thallia has quit [Ping timeout: 256 seconds]
eduardo__ has quit [Ping timeout: 260 seconds]
thallia has joined ##openfpga
<rqou>
azonenberg: discuss: your JtagInterface is too high-level for me to implement certain ideas such as duct-taping in xilinx xvcd
<rqou>
the xvcd protocol gives two buffers of data to put on tdi and tms, and they are clocked into the target at the same time
<rqou>
can you add a FootgunMe(const unsigned char *tms_data, const unsigned char *tdi_data, unsigned char *tdo_data, int count)
<rqou>
or do you really really want to enforce doing the "correct" thing with the jtag state machine?
<sorear>
can you briefly explain what's wrong or a footgun about that interface?
Bike has joined ##openfpga
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has joined ##openfpga
clifford has quit [Read error: Connection reset by peer]
clifford has joined ##openfpga
digshadow has quit [Ping timeout: 240 seconds]
<mithro>
Morning everyone!
<mithro>
daveshah: how goes the exam study?
<daveshah>
mithro: Almost done (just a German oral exam tomorrow), hence the VPR commits today :)
<mithro>
Your learning German?
<mithro>
Dammit, I'm going to be the only openfpga contributor which is mono-lingual :-/
<mithro>
You can all talk about me behind my back ;-)
<daveshah>
mithro: I'm about to spend 6 months in Vienna :)
<daveshah>
mithro: Google Translate breaks that idea these days... (not that I would be gossiping behind your back of course :-P)
* ZipCPU
might be ...
* ZipCPU
doesn't know German though.
rohitksingh has quit [Quit: Leaving.]
m_w_ has joined ##openfpga
<awygle>
pero ningun hablamos la misma idioma
* awygle
regrets how long it's been since he spoke Spanish for real
* awygle
is seriously second guessing the grammar of that sentence
<awygle>
Oof yeah that was pretty wrong. Oh well.
<ZipCPU>
Yeah, that happens to me when I try to speak SVA. :P
<awygle>
I speak Japanese poorly and Spanish pretty well (or used to), and for some reason "demo" and "pero" are all tangled up in my head, I frequently grab the wrong one for the language I am using.
digshadow has joined ##openfpga
FabM has joined ##openfpga
<rqou>
Japanese? weeb :P
<rqou>
azonenberg: it doesn't make sense to shift any data into a jtag device unless it's actually in Shift-IR/DR, does it?
<rqou>
also awygle maybe?
<azonenberg>
rqou: correct, it doesnt
<azonenberg>
Re duct taping in xvcd, do you mean as a client or server?
<rqou>
azonenberg: what do you think about the proposed FootgunMe?
<azonenberg>
i.e. do you want a jtaghal dongle to look like a xvcd
<rqou>
yes, that
digshadow has quit [Ping timeout: 268 seconds]
forrestv has quit [Ping timeout: 276 seconds]
rqou has quit [Remote host closed the connection]
awygle has quit [Remote host closed the connection]
rqou has joined ##openfpga
FabM has quit [Quit: ChatZilla 0.9.93 [Firefox 52.7.2/20180316222652]]
<azonenberg>
hmmm
<azonenberg>
your proposed api might not even be possible to implement
<azonenberg>
see, the issue is that depending on the adapter in question
<azonenberg>
and i was willing to consider
<azonenberg>
because the opposite is fairly easy
<azonenberg>
also the higher level api provides a lot of useful optimizations
<azonenberg>
like letting you skip state transitions that are redundant b/c you are already in shift-dr, etc
<azonenberg>
The instant you touch raw data all bets are off
awygle has joined ##openfpga
<azonenberg>
my assumption at the time i designed it was that jtagclient or a custom C++ app was going to be talking to $something
forrestv has joined ##openfpga
<azonenberg>
if anything, future hardware will (in the interests of performance) be moving to an even *higher* level api
<azonenberg>
f.ex starshipraider is likely to move the "set IR of device 3 to 0xdeadbeef" api into hardware
user10032 has joined ##openfpga
<rqou>
so i need the opposite of diamondman's thing :P
<azonenberg>
honestly if i wanted to implement the xvcd protocol
<azonenberg>
i'd make a bridge core that parses the incoming tms stream
<azonenberg>
and figures out state transitions
<azonenberg>
then calls the mid level api
<rqou>
which requires "the opposite of what diamondman wrote"
<azonenberg>
Also, JtagInterface::ShiftTMS is a legal function
<azonenberg>
however it's protected specifically to prevent anyone but a JtagInterface implementation from using it
<azonenberg>
that was an explicit goal, it's not meant to be used except by the mid-level API
<azonenberg>
And i wanted implementations to be free to assume chain state wasn't changing from under them
<rqou>
um, i can always just make a FootgunFTDIJtagInterface that exposes it :P
<azonenberg>
I currently have code that relies on that, in fact
<azonenberg>
for higher performance
<rqou>
imho "protected" is pretty useless
<azonenberg>
rqou: if you derive from my class i assume you know what you're doing
<azonenberg>
Private = "I'm certain i will never have to change the implementation in the future and want to be footgunned out of improving anything"
<azonenberg>
Protected = "not part of the public API, but if you need to replace it override the class"
<azonenberg>
public = intended for general consumption
<rqou>
have you not seen hacks like FFIPARInterface? :P
<azonenberg>
as a rule i never private anything
<azonenberg>
unless i have a REALLY good reason to not want a derived class touching it
<azonenberg>
Anyway, my point was
<azonenberg>
some of my code actually does optimizations to prevent state transitions if you're already in that state
<azonenberg>
Look at JtagDevice::SetIR() for example
<azonenberg>
If you set IR to the same value it's already in, it's a nop and never touches the hardware
<azonenberg>
The instant you allow low-level access without doing this, things break
<azonenberg>
(in fact this is an argument to restrict the state-level interface from general use too!)
user10032 has quit [Quit: Leaving]
<azonenberg>
or as a minimum have it invalidate all cache data
<azonenberg>
i put a lot of work into optimizing jtaghal to avoid unnecessary jtag traffic because a round trip to the dongle is SLOW, especially if connected via usb instead of something like ethernet
<azonenberg>
a scan-and-wait-for-response call is a minimum ~1ms delay
<azonenberg>
That's also why i have the deferred "send data and don't wait for a response" API
<azonenberg>
and command batching, etc
<azonenberg>
I've hit something like 9.5 Mbps of actual application-layer throughput with a 10 MHz TMS, and that takes some work
<azonenberg>
the naive version full of what's effectively usleep(1000) calls everywhere is a lot less efficient :p
<azonenberg>
rqou: also re your jtagd issue #2 i've been aware of it for a long time but it's a low priority issue and i never bothered to do anything about it
<azonenberg>
basically what i do to shut down is call close() on all sockets then wait until stuff shuts down
<azonenberg>
but this makes accept() abort with an error code
digshadow has joined ##openfpga
<azonenberg>
The only good fix i see is just to shut down the log sink when you ^c before closing the sockets
<azonenberg>
I'll review the other issues tonight after work
<rqou>
the libftdi stuff is probably too hacky at this point
<rqou>
it probably needs some mpsse-common stuff to get refactored out
<azonenberg>
oh also another thing that would be nice is to support more generic ftdi stuff somehow
<azonenberg>
right now i support my own dongle and the HS1, which both need a certain gpio to be set as an OE for it to work
<azonenberg>
but not all dongles are wired this way
<rqou>
ugh
<rqou>
openocd has a giant f*cking hack for this
<azonenberg>
the mpsse is generic but the h/w its hooked up to is not
<azonenberg>
also incidentally, on linux it's very hard to have one instance of a vid/pid pair using driver X
<azonenberg>
and another using driver Y
<azonenberg>
it may not even be possible?
<rqou>
yeah, have you seen openocd's ftdi_layout_init/ftdi_layout_signal?
<rqou>
azonenberg: why do you need that?
<azonenberg>
(no)
<azonenberg>
rqou: I don't, thanks to some eeprom
<azonenberg>
my original plan was to have my jtag dongles just be vanilla ft232h using default vid/pid
<azonenberg>
problem is, if you configure those as jtag
<azonenberg>
you lose the ability to ever use a ft232h with default config as a uart
<rqou>
what
<whitequark>
what
<rqou>
no you don't?
<whitequark>
we use that at $work
<azonenberg>
As of when i last checked, it didnt work
<whitequark>
or at least i'm pretty sure we do
<azonenberg>
you had to detach the ftdi_sio driver
<azonenberg>
and attach d2xx
<azonenberg>
which was a separat ekernel driver
<azonenberg>
and you can only have one kernel driver per vid/pid
<rqou>
er, no it isn't
<whitequark>
yeah, we use libusb
<azonenberg>
oh, ok
<azonenberg>
so if you sidestep the driver stack then thats diff b/c the kernel driver is now libusb.ko
<azonenberg>
for everything
<rqou>
yes
<rqou>
afaict even ftd2xx works that way
<azonenberg>
But you cannot use d2xx and ftdi_sio simultaneously for the same vid/pid
<azonenberg>
That much i know
<rqou>
probably correct
<azonenberg>
Which is why i got my own PID from ftdi
<azonenberg>
and use that for my dongles
<rqou>
wait, what do you mean "for the same vid/pid"
<azonenberg>
ftdi:that is always jtag and ftdi:232h is always uart
<azonenberg>
rqou: my understanding is that a kernel driver is attached to all instances of a vid/pid combo
<rqou>
that's definitely not the case
<azonenberg>
and you cant do it separately by device
<azonenberg>
maybe it was ftdi_sio being too grabby then
<rqou>
you can unbind/disable the kernel driver per-device
<azonenberg>
i just know i had to full-on unload the driver to make it work
<rqou>
it's always worked for me on linux
<azonenberg>
its possible it would work if i was root or something?
<azonenberg>
anyway, i sidestepped the issue by using a custom pid
<whitequark>
you can unbind the kernel driver per device (it's an ioctl)
<rqou>
you don't need root, you just need access to the usb device node as the current user
<whitequark>
however, i don't think you can *bind* a kernel driver per device
<azonenberg>
whitequark: oooh so that might have been it
<azonenberg>
i might not have been able to bind ftd2xx to the device while others were claimed by ftdi_sio?
<rqou>
er, i think you can reattach "whatever driver the device thinks is suitable" per-device
<whitequark>
yes
<rqou>
*the kernel
<whitequark>
but not a specific one
<azonenberg>
either way, if you wanted to use both the termios api through /dev/tty* and d2xx
<whitequark>
the kernel has a mapping from VIDPID to kernel driver
<azonenberg>
the easiest option seemed to be to mux by pid
<rqou>
yeah, if you want a specific one you have to monkey around with sysfs
<whitequark>
no, you can't even do that via sysfs
<whitequark>
sysfs only lets you alter the VIDPID to driver mapping table
<rqou>
you can for pci/pcie
<whitequark>
not for usb
<rqou>
hmm
<azonenberg>
like i said, having one pid for uart and one for jtag makes the most sense to me
<azonenberg>
if anybody wants to make ftdi jtag dongles (why would you do this?) that are compatible with mine, feel free to use 0403:8028
<whitequark>
well i might use that
<whitequark>
except i'm not ftdi
<whitequark>
i'm a reimplementation of mpsse
<azonenberg>
whitequark: well that's technically violating some license somewhere i think, but hey - if you're truly api compatible i dont care
<azonenberg>
the one thing to keep in mind is that my dongle does use one gpio, i forget the particular pin, as an OE
<azonenberg>
(it's the same pin that the digilent hs1 uses, mine is api compatible but a different pid)
<rqou>
whitequark: i see the same "bind" and "unbind" sysfs files for usb as for pci
<rqou>
are you sure it doesn't work?
<whitequark>
azonenberg: i can map any ftdi gpios to any pins in gateware :P
<azonenberg>
whitequark: lol
<azonenberg>
just saying, if you see me set this pin that's why - and don't try to use that pin as a gpio or you'll get random noise on it
<rqou>
btw the ftdi driver situation is absolutely dreadful on win/mac
<rqou>
it's acceptable on linux
<rqou>
because win/mac both don't have the "kernel driver plz 2 go away kthx" unbind interface
<azonenberg>
i think that may have been the other reason i did a custom vid/pid
<azonenberg>
So i could (if i wanted) explicitly bind d2xx to my pid in a .inf
<rqou>
and afaict on macos you definitely can only use one or the other
<azonenberg>
it may not have been linux
<azonenberg>
jtaghal is mostly cross platform, i may have one or two posix-isms here and there but it was intended to be ported to win/mac at some point if i wanted to
<rqou>
on windows you can manually set some dongles to libusb-compatible using zadig
<azonenberg>
(jtagd is definitely posix-y in a few spots)
<azonenberg>
But again, will accept PRs to make that better
<rqou>
i think it remembers it using either the position in the bus or using the serial number
<rqou>
on mac i think it's either all-or-nothing or requires a whole bunch of monkeying with IOKit that nobody has ever figured out how to do
<rqou>
i would be much less unhappy with macos if "codeless kexts" (what a dumb feature) didn't need signing
<rqou>
hmm, azonenberg do you know anything about macos security? does modern macos have KPP? i know ios does now
<rqou>
if not, i'm thinking of writing a "user-friendly" "codesigning f*ck off" tool that just uses an ancient signed vulnerable driver to disable driver signing
<jn__>
what is a "codeless" kernel extension?
<azonenberg>
rqou: eeeew
<rqou>
basically a .plist that forces the default kernel driver to not load
<rqou>
azonenberg: eeeew what?
<azonenberg>
everything you suggested? :p
<rqou>
why?
<rqou>
it's more user-friendly than telling people to go into the recovery environment and use csrutil
<whitequark>
rqou: so a codeless kext is just a .inf file basically
<rqou>
i know
<rqou>
hence why requiring signing is dumb
<rqou>
hmm, apparently in high sierra apple is trying to block my proposed approach
<rqou>
i guess you really have to do it "properly" and tell the user to use csrutil
<azonenberg>
rqou: any time your planned solution to a problem is "patch the kernel" you're doing it wrong :p
<rqou>
why?
<azonenberg>
KPP exists for a reason
<azonenberg>
oh, and the PROPER solution would be to get funding for an actual code signing cert and re-sign the d2xx driver for your 0403:8028
<rqou>
yeah, to enforce DRM protections
<azonenberg>
...
<rqou>
on windows at least
<azonenberg>
no, that isnt why - that's a side benefit
<azonenberg>
i'm sure the mpaa was happy
<azonenberg>
but the #1 reason was to get rid of all of the complaints about bsods and system instability that were super hard to debug
<azonenberg>
from buggy antivirus patching syscalls left and right
<rqou>
that's only because they suck
<azonenberg>
they explicitly wanted to force av out of that
<sorear>
are we still talking about macOS? I've never seen a macOS system with AV
<rqou>
no, now we're talking about windows
<rqou>
macos doesn't have KPP (only ios does)
<rqou>
also azonenberg according to rumors apple doesn't easily grant kext signing certs
<rqou>
this isn't a problem on windows anyways because you don't modify the actual ftdi .sys, only the .inf
<rqou>
and you can still install the driver after dismissing some security toasters
<rqou>
again why needing signing for "codeless kexts" is dumb
<balrog>
Windows also requires signing for codeless infs
<balrog>
:/
<rqou>
er, no it doesn't?
<rqou>
it gives you a big scary toaster but allows you to install it anyways
<rqou>
still no actually good light field camera :(
<rqou>
azonenberg: homeoptics in addition to homecmos? :P
<lain>
rqou: it does require signing codeless infs
<lain>
iirc you have to be in test mode to bypass that restriction
<lain>
at least on win8, win10
<lain>
older versions may be more permissive, I forget
<rqou>
I've definitely installed modified infs on win10
<rqou>
e.g. using zadig
<lain>
rqou: zadig uses libwdi, which auto-generates a cert on the fly, adds it to your trusted root store, and signs the generated inf with it.
<rqou>
lain: but that doesn't require a silly fancy kernel mode cross cert
<rqou>
also, I'm almost certain I've managed to get modified infs to install with a toaster
<lain>
in windows there's no special cert for drivers
<lain>
it's just an AuthentiCode cert, same as you'd use for signing an exe
<lain>
and it can equally be any cert in your trusted root store
<lain>
if you did manage to install unsigned certs, you were likely in test mode.
<lain>
er, unsigned drivers**
<rqou>
there is definitely a special cert for drivers
<rqou>
it's still authenticode, but the CA needs a special cross cert from Microsoft
<digshadow>
rqou: I thought lytro went under
<rqou>
nope
<digshadow>
I actually had a pile of lytro engineering unit cameras I got at auction
<rqou>
O_o
<digshadow>
like a hundred of them
<rqou>
do you still have them?
<digshadow>
no I trashed them
<lain>
rqou: I mean, I purchased a bog standard AuthentiCode certificate and used it for driver signing and it works fine, and everywhere I've seen CAs selling AuthentiCode, they say it can be used for driver signing... ¯\_(ツ)_/¯
<digshadow>
they came with something else I was getting
<rqou>
lain: because most of the really big CAs have the cross cert
<rqou>
the smaller ones don't
<rqou>
hence why i call it a drm enforcement scheme
<lain>
heh
<rqou>
digshadow: what was the other thing?
<rqou>
lain: in general, imo the whole pki ecosystem is only good for being a protection racket and enforcing drm
<lain>
rqou: Windows is closed-source though so if the complaint is that the cross-cert allows MS to control whose drivers you can and cannot install, they can control that regardless of pki
<lain>
but I dunno, even I'm moving away from windows these days. MS's behavior in recent years is excessively user-hostile, and I can't deal with it anymore :P
<rqou>
yeah, i agree
<rqou>
btw, apparently Mozilla is too (but still better than the alternatives)
<lain>
eh, I'm happy with chrome
<lain>
firefox quantum is fast though, I'll give it that. but it seems to eat a lot of cpu, and they keep removing really useful UI elements (at a rate faster than chrome has been removing them, at least)
<lain>
though chrome keeps finding new and exciting ways to hide the certificate information
<lain>
which is preeeetty infuriating tbh.
<rqou>
random offtopic rant that only awygle will understand: i hate how _only_ the top floor of Cory is impossible to walk around in a loop
<azonenberg>
rqou: you haven'
<awygle>
UGH yes
<azonenberg>
you haven't seen Sage Lab at RPI
<azonenberg>
They have multiple spots on some floors that do not connect
<azonenberg>
you have to go up/down to travel between them
<rqou>
in general, this building is a great example of "we planned for the future that never came to pass"
<awygle>
So many Cal buildings are so badly designed. The engineering ones are among the *best*
<azonenberg>
it's a maze and even when i was ready to graduate there were still areas that I couldn't navigate between
<rqou>
azonenberg: wtf
<azonenberg>
rqou: tl;dr they have multiple isolated blocks on the... 4000 level?
<azonenberg>
that are kinda like towers
<awygle>
What's the big ugly one where the bottom floors are discontinuous and there are half floors?
<azonenberg>
sticking up from the main building
<azonenberg>
you have to go donw to the 3000 level to go between them
<azonenberg>
i forget which floor it is
<azonenberg>
but it exists
<rqou>
awygle: "you enter dwinelle as a freshman and only find the exit as you're about to graduate"
<awygle>
Dwinelle, that was it
<awygle>
250 Dwinelle is on floor 2.5
<azonenberg>
lol, i guess all college campuses are like that
<azonenberg>
the Low building at RPI has ground-level access on the 1000, 2000, 3000, and 4000 levels
<azonenberg>
:D
<azonenberg>
or is it just 1/2/3? i forget where the one up the hill is
<rqou>
awygle: "foobar office is in 1234F Dwinelle Annex" --> "you're screwed"
<awygle>
Lol yeah, there goes your day
<rqou>
the CS building has ground level access on floors 3 and 4
<awygle>
Cory and the civvie building have that "3-4 ground level entrances" issue
<awygle>
I used to use Cory's elevators to avoid climbing the hill to soda
<rqou>
Cory has access on levels B, 1, and 2 which isn't _too_ unreasonable considering it's built on a hill
<rqou>
although they changed the default permissions so only grad students have access to the basement exterior door now, idk why
<rqou>
meanwhile the CS building default perms allow exterior door access to the fourth floor but _not_ elevator access
<rqou>
so you need to use the stairs and exit to outside (yes, the stairs have an exit to outside) just to immediately re-enter
<rqou>
awygle: you know about the tricks to use eecs access to get access to SDH/Etch, right?
<pie_>
the fuck lol
<rqou>
Berkeley is a bit screwy because of legacy
<rqou>
also because theft, and also because Unabomber
<awygle>
Yeah course, I used to have to do that to get to my advisor's office
<rqou>
lolol
<rqou>
when safety regs and access controls collide, safety wins (also add in a dose of legacy)
<rqou>
for everybody else: the CS building unintentionally gives access to the ME building
<rqou>
because the first floor of the CS building is actually underground, so it needs an emergency exit
<pie_>
aha
<rqou>
so they built a tunnel and an un-alarmed exit to the ME building
<rqou>
which is lower on the hill so the same floor is at ground level in that building and no longer underground
<rqou>
meanwhile, the EE building has a bridge to the "fancy big money engineering collab" building
<rqou>
there are two sets of access controls, one for each direction
<rqou>
the one inbound to the EE building is pretty chill while the other is full of turf wars
<rqou>
but the readers are mounted near the same door, and NFC is "near field," not "only in the front field"
<rqou>
the other building can no longer have access controls because for safety reasons you can't strand people on the bridge/balcony area
<rqou>
azonenberg: why are physical access controls so difficult?
<azonenberg>
rqou: i'm starting to deal with this at my new place
<azonenberg>
i think that the lab may have to be the fire exit for the downstairs bedrooms (you need a grade-level exit if the stairs to the main level are on fire)
<azonenberg>
Which means i can't lock the lab
<rqou>
HID 125kHz is the best security! just trust us, we're a vendor!
<rqou>
:P
<azonenberg>
So how the fsck do i childproof that?
<rqou>
childproof?
<azonenberg>
We may have a nerdling eventually
<azonenberg>
i want to plan for the possibility in the architecture
<rqou>
eww
<rqou>
although i guess catproofing is a thing too
<azonenberg>
dog but yeah
<azonenberg>
anyway best option i have right now is to get one of those emergency exit bars they have in public buildings
<azonenberg>
Normal access: use key to disarm alarm and unlock door, walk in, door closes and locks behind you
<azonenberg>
emergency access: push and hold button, alarm sounds immediately
<azonenberg>
door unlocks in 15 sec
<rqou>
🐈>🐕
<rqou>
:P
<awygle>
rqou: at last we agree :-P
<jn__>
wow, i didn't know my font set had cat and dog glyphs
<jn__>
but then again, i installed noto, so i ought to have all the glyphs
* awygle
needs to stop petting the cat and get back to work
<rqou>
🐈>🐕>>>👶
<awygle>
Today is bad, y'all
<rqou>
cat disagrees :P
<azonenberg>
noo puppers
* pie_
experiences a distinct lack of cuddles
<rqou>
yeah, I don't currently have a cat either
<rqou>
azonenberg: fine, we'll just sprinkle in a dose of PHP fucked comparison operators such that 🐈>🐕>🐈 :P
<rqou>
some stm32s can bypass option bytes if you have code execution
<rqou>
cc azonenberg
<azonenberg>
innnteresting
<rqou>
does _any_ microcontroller code protection actually work?
<rqou>
we should spend some time and break the shit out of modern uC code protection
<rqou>
it seeems like older parts are actually better because it has fewer features
<azonenberg>
lol
<azonenberg>
this has been on my research list for a long time
<azonenberg>
but i always have higher priority projects
<rqou>
azonenberg: would you agree that "one floating gate cell is connected to the readback circuitry" is much more likely to be implemented correctly vs modern in-circuit debug and self-flashing things?
<azonenberg>
Yes
<azonenberg>
I'm always a fan of security through stupidity
<azonenberg>
if you physically AND the path from the flash to TDO with the code protect bit
<azonenberg>
Good luck defeating that without flipping that bit somehow
<sorear>
read back the chip under a power analysis rig? the data isn't making it to TDO but it's still being read
<rqou>
right, but that's arguably a much more advanced technique
<azonenberg>
i mean you can also gate earlier in the chain etc
<azonenberg>
e.g. blocking TCK from touchign the readback circuit
<azonenberg>
And yes its also a more advanced technique
<rqou>
also, apparently you can never read datasheets too carefully
<azonenberg>
oh?
<azonenberg>
what'd you find
<rqou>
i mean, this stm32 bug could probably have been found by reading between the lines in the datasheet
<balrog>
[17:54:13] <rqou>it seeems like older parts are actually better because it has fewer features
<balrog>
lol
<balrog>
yes and no
<azonenberg>
a lot of older parts were trivially UV-able
<rqou>
"To run any operation on this sector, the option lock bit (OPTLOCK) in the Flash option
<rqou>
control register (FLASH_OPTCR) must be cleared. To be allowed to clear this bit, you have to perform the following sequence:"
<rqou>
hmm, so this "vuln" is explicitly documented
<azonenberg>
what's the bug exactly?
<azonenberg>
didnt read the original post yet, busy
<rqou>
on that particular bitcoin wallet, you can load custom fw, but doing so wipes the keys
<rqou>
the custom fw can modify the option bytes and un-protect the bootloader
<rqou>
you can then load a trojan fw undetectably
<azonenberg>
My recollection was that de-protecting memory forced a full chip wipe?
<rqou>
no
<azonenberg>
huh thats strange
<rqou>
hmm, only for read protection
<rqou>
not for write protection
<azonenberg>
Well i guess the idea was they wanted to allow firmware updates
<azonenberg>
But not let you dump it
<azonenberg>
that seems reasonable
<azonenberg>
Allowing arbitrary code execution on a critical device seems like a horrible idea
<rqou>
yeah, so i guess it's just a misfit with what trezor wanted
<azonenberg>
also, re loading trojan FW
<azonenberg>
that wipes keys
<azonenberg>
so is the concern the device being mitm'd before reaching you?
<rqou>
the idea is for a supply chain attack
<azonenberg>
well the easiest fix imo is to ship the device blank and supply a signed rom file on their website :p
<rqou>
btw azonenberg on esp32 there is code encryption that allows blindly swapping pairs of 16byte chunks. exploitable?
<azonenberg>
Probably, yes
<sorear>
how is that encryption
<azonenberg>
sorear: it's probably a counter mode AES
<azonenberg>
or something along those lines
<rqou>
ECB afaict
<azonenberg>
ecb? lol
<azonenberg>
so yeah it replaces every 128 bits of code with 128 other bits
<rqou>
not "normal" ecb
<azonenberg>
but you can swap blocks around
<rqou>
er, aes-not-quite-ctr
<sorear>
ok, from rqou's description I had in mind something vastly simpler than aes
<rqou>
aes-256-ecb over 2 16 byte blocks where every 32 bytes the key is xored with the address in some weird way
<rqou>
does that make any sense?
<azonenberg>
rqou: oh wait, so its only pairs
<azonenberg>
its not arbitrary 128-bit blocks
<azonenberg>
thats really strange
<rqou>
yes
<azonenberg>
it seems like a corruption of some disk encryption mode misimplemented or something lol
<rqou>
it seems like they didn't understand that they actually wanted counter mode or something
<balrog>
azonenberg: some weren't
<rqou>
the thing is, it's not obviously completely busticated
<balrog>
some PICs are pretty difficult, as are many AVRs
<rqou>
(the esp32)
<rqou>
but it's definitely fishy
<balrog>
rqou: wait, who's using esp32 for what?
<rqou>
nobody
<rqou>
i just happened to read the docs for it the other day
<rqou>
i just want _all_ the crp bypasses
<rqou>
hmm, actually
<rqou>
azonenberg: ctr mode is even more unsuitable here
<azonenberg>
rqou: honestly i'd use GCM on each flash row
<azonenberg>
with the auth tag
<rqou>
there's a trivial bypass with ctr mode
<rqou>
the problem is that this is XIP
<rqou>
otherwise yeah, GCM is good
<rqou>
XIP+AEAD is hard
<sorear>
how much latency are you willing to add for the decryption and authentication?
<rqou>
as little as possible :P
<sorear>
alternatively you can move the tag calc out of the critical path by accepting some number of cycles of running unauthenticated code
<rqou>
still sounds fishy to me
<rqou>
anyways, i think i have a way to leak at least one byte at the beginning of each block the way the esp32 did it
<rqou>
hmm, there's also a mac that can be enabled
<rqou>
wtf, it uses a nonstandard algo too
<awygle>
what would you name an ice40 LM dev board in the same form factor as the tinyfpga b2?
<rqou>
hugefpga c3? :P :P
<rqou>
anyways, i really want some esp32s now to test my theory
<awygle>
i have one
<awygle>
somewhere
<rqou>
i _think_ i have a workable code protection bypass
<rqou>
assuming there's only encryption, not secure boot
<awygle>
small castellated "this has lots of chips in it but pretend it's just one chip" modules make me happy
<azonenberg>
awygle: lol yeah i have one of those on starshipraider
<azonenberg>
i've seen them in BGA form factor too
<azonenberg>
(actually i think the one on starshipraider is a BGA)
<awygle>
it reminds me of what somebody said about PCB technology approaching old IC technology
<awygle>
rqou: does your cmake pr for libjtaghal do the right thing when you have both ftdi libraries installed?
<rqou>
it builds both
<rqou>
but you probably only want to merge the first PR for now
<rqou>
the second one has a gross amount of copypasta
<rqou>
azonenberg: anyways, what do you think about my esp32 code encryption idea:
<rqou>
it needs a lot of fleshing out, but the idea is that you bruteforce one aes block such that it ends with a pc relative load opcode
<openfpga-bot>
[jtaghal-cmake] awygle closed pull request #1: Properly link libftd2xx if available (master...master) https://git.io/vxcgp
<rqou>
you can tell it worked by monitoring for a fetch from the spi flash
<rqou>
you then bruteforce the second aes block until it has a branch
<openfpga-bot>
[jtaghal] awygle pushed 2 new commits to master: https://git.io/vxWqY
<openfpga-bot>
jtaghal/master 3e36ccf awygle: Merge pull request #2 from rqou/master...
<openfpga-bot>
jtaghal/master 2d806b6 Robert Ou: Properly link libftd2xx if available
<rqou>
the branch then leaks the data that was loaded
<azonenberg>
That sounds very reminiscent of meltdown/spectre
<rqou>
and then you mumble mumble and piece together all the pieces
<rqou>
it's a bit inspired by both that and the 3ds hacks
<azonenberg>
Sounds totally plausible
<rqou>
and i just started looking at this yesterday :P
<rqou>
uC security is hopeless
<azonenberg>
Lol
<azonenberg>
on a totally different note
<azonenberg>
i've been using chipscope on this virtex board a bunch since i'm doing a non-antikernel dev environment for the project
<azonenberg>
and the vivado seat comes with a chipscope license
<azonenberg>
mostly have feature parity with my LA
<azonenberg>
i have compression which they lack
<rqou>
does compression actually work?
<azonenberg>
If you have long periods where there's no toggling on any input, i just store the delta to the next toggle
<azonenberg>
it's done globally, not per channel
<azonenberg>
They have a segmented capture mode i lack, which provides some of the same capabilities as compression but less granularly
<azonenberg>
i'm actually considering implemnting both
<azonenberg>
i.e. compression within each segment of a segmented capture
<awygle>
is "segmented capture" the same as multiple triggers?
* awygle
is more familiar with the lattice family of tools at this point
<azonenberg>
Basically yeah, you split the capture buffer into N blocks and trigger separately for each block
<awygle>
yeah, that's super useful
<azonenberg>
the vivado LA (the correct term, it replaces chipscope but probably shares most of the same code) also has the ability to enable trigger per channel
<azonenberg>
redtin has every channel trigger capable all the time and osmetimes you know you'll never trigger on a given input
<azonenberg>
so optimizing that out is nice
<azonenberg>
Other than that it's mostly feature parity, we both have trigger in/out etc
<azonenberg>
nice to study the competition though
<awygle>
lol
<awygle>
i still want my clock gated single stepping live debug idea
eric_ has quit [Read error: Connection reset by peer]
<awygle>
even if it's not useful for big boy professionals i bet it would help noobs enormously
<azonenberg>
yeah i pretty much always work on hard realtime things like ethernet that have a fixed clock rate required
<awygle>
well sure. but you also work on state machines and stuff that hang off of those hard realtime busses. you telling me you've never had an off-by-one-cycle error in a state machine?
<azonenberg>
i had one last night :p but i debugged it in real time on hardware
<sorear>
mumble INTEST
eric_ has joined ##openfpga
mumptai has joined ##openfpga
<awygle>
i debug stuff like that from traces all the time but it would be a lot easier to do if i could single step imo
<rqou>
you mean you don't debug my opening a huge waveform viewer and staring at it seeing where the mismatch is? :P
<awygle>
that's exactly what i do and it sucks :P
<rqou>
my software housemate also complained that it seems hardware debuggers suck a lot harder than software debuggers
<azonenberg>
need moar formal
<azonenberg>
rqou: the state of the art in "software engineering" tools for RTL is decades behind software
<azonenberg>
that being said, hardware uses a lot more formal than software
<awygle>
Super Extra Bonus Points if you can live-rewire your ILA to catch a different set of signals without rebuilding the bitstream
<awygle>
(note - not sure the above is actually possible)
<azonenberg>
awygle: older chipscope at least, idk how to do it in vivado, could do that with a partial re-par of only the LA
<azonenberg>
kinda gluing itself around your logic
<azonenberg>
i dont know if vivado is able to do this
<azonenberg>
our toolchain needs to have this as a priority
<awygle>
how about "grab all unused global routing resources for ILA traces"
<awygle>
then just poke whatever flop you need
<awygle>
that would be cool
* awygle
suspects sorear is right and he's reinventing INTEST or similar
<azonenberg>
lol "all unused routing" is a bit tricky re power etc :p
<awygle>
all unused _global_ routing
<rqou>
awygle: don't you work for data io? shouldn't you be intimately familiar with this? :P :P
<awygle>
clock nets, reset nets, etc
<azonenberg>
and you'd still have to figure out specifics
<azonenberg>
as far as which flop to grab
<azonenberg>
there would need to be like a map file generated by the par that says what data is where
<awygle>
yeah that requires a substantial improvement in bitstream pokey-pokey
<azonenberg>
you'd have to preserve mappings of synth net names down to hardware too
* azonenberg
stabs ABC
<awygle>
UGH yes
<awygle>
i am very concerned about ABC
<awygle>
as a fundamental underlying part of our toolchain
<azonenberg>
There is a good chance we will have to replace it at some point
<rqou>
why?
<azonenberg>
But short term i want a good PAR
<rqou>
you'll make the research group sad
* awygle
side-eyes the folder labeled "majority inverter graph papers"
<azonenberg>
rqou: because it makes traceability through implementation nearly impossible
<azonenberg>
it destroys everything regarding net/primitive names
<rqou>
awygle: both you and pointfree :P
<awygle>
oh? did not know
<rqou>
azonenberg: isn't that fundamentally unfixable?
<awygle>
pointfree always seems to have a much better theoretical basis than i do
<rqou>
if you want access to certain nets, you limit the possible optimizations
<azonenberg>
rqou: the goal is to ensure that those nets which are not optimized out
<azonenberg>
preserve names similar to their original
<awygle>
rqou: all you need is that the nets resulting from optimization is labeled with the name of _some_ net from the bitstream
<azonenberg>
And also have the ability to constrain certain nets as "don't optimize, preserve this intermediate for debugging"
<rqou>
awygle: don't you have a fancy piece of paper too? where's your theoretical background? :P :P
<azonenberg>
i.e. you can optimize before and after but keep that node
<rqou>
azonenberg: can't you already do that by very carefully writing a yosys script that causes yosys to only tell abc to optimize parts of the design at once?
<azonenberg>
rqou: idk... but the net name preservation is critical
<azonenberg>
i want to be able to trace a post implementation net back to rtl
<sorear>
about how much optimization are we doing? is retiming a thing yet/
mumptai has quit [Quit: Verlassend]
<rqou>
yes, retiming has worked for quite a while
<azonenberg>
ise does this well, vivado so so
<azonenberg>
eeeh
<azonenberg>
Synth time retimng
<rqou>
yeah, not PAR-time retiming
<azonenberg>
i want par time retiming to balance routing delays
<awygle>
does vpr do PAR-time retiming? (mithro)
<azonenberg>
Which dominate on fpga
<azonenberg>
oh and, as part of that
<rqou>
btw azonenberg do xilinx parts actually implement boundary scan? or only programming?
<azonenberg>
Being able to tweak placement based on overall timing
<azonenberg>
i.e. dont say "oh this net is super critical let me place it right next to other stuff"
<azonenberg>
but instead say "this net is failing timing, let me move this flop two levels earlier then place it further away"
<azonenberg>
so multiple iterations of place-and-retime
<azonenberg>
rqou: yes they implement full extest/intest although jtaghal does not currently support that
<azonenberg>
i've never had a use case, i can just load a custom bitstream for pcb test
<awygle>
extest is super useful but also kind of terrifying
<azonenberg>
Have you ever actually used it?
<azonenberg>
i guess maybe if you have a lot of mcus or other chips that support boundary scan on dedicated pins
<azonenberg>
but on an fpga it seems pointless
* awygle
has A Story about extest
<awygle>
imagine hypothetically that you had an MCU which was programmable over JTAG but which abused TDI such that it could not be in a chain, only by itself
<rqou>
wtf
<rqou>
but i've heard of that
<awygle>
imagine further that you had a "JTAG buffer" chip which was supposed to be for pattern testing and such but which supported EXTEST and being in a proper chain
<awygle>
if you were so inclined, you could hook up pins from the JTAG buffer to the MCU's JTAG pins and implement "JTAG over JTAG"
<awygle>
to allow reprogramming a large system of MCUs from a single master
<pie_>
rqou, i wonder if that would be poc||gtfo worthy
<rqou>
if what?
<pie_>
also there was something in the 34c3 edition about aes fuckery
<pie_>
not quite sure how related
<pie_>
but it sounds at least vaguely reminescent
<awygle>
(you could also then wrap JTAG over JTAG in a custom protocol and try to do reliable programming over a radio link with PER ~1%)
<rqou>
wtf
<azonenberg>
awygle: sooo
<azonenberg>
I've done jtag over [insert long list here] over jtag
<rqou>
was it at least a bidirectional radio link or was it using fountain code magic?
<awygle>
bidirectional half-duplex
<awygle>
hypothetically
<rqou>
ok, so there are acks
<azonenberg>
awygle: tl;dr i was debugging a jtag master core for antikernel
<azonenberg>
The core lived on the antikernel noc
<rqou>
not just "thoughts and prayers"? :P :P :P
<azonenberg>
I had a debug bridge that transferred noc frames over jtag
<sorear>
is "PER ~1%" redundant or does the P stand for something I'm not getting?
<awygle>
packet
<awygle>
as opposed to bit error rate
<azonenberg>
then i accessed the debug bridge over jtag from my pc
<azonenberg>
the jtagd was accessed over tcp by a noc-to-jtag bridge app
<azonenberg>
nocswitch was then accessed over tcp
<rqou>
btw awygle are you aware of fountain codes?
<rqou>
f*cking black magic :P
<azonenberg>
So i ended up having two tcp sockets, a usb-jtag link, then real jtag
<azonenberg>
end to end
<azonenberg>
then the antikernel noc
<azonenberg>
tunneling... more jtag
<awygle>
azonenberg: trust me when i say that using EXTEST and the other one (SAMPLE/PRELOAD i think?) to bit bang jtag is worse :p
<azonenberg>
awygle: oh i believe it
<awygle>
i think our end to end performance was like... 100 Bps
<sorear>
fountain codes seem like a poor fit for this channel, hard to implement without RAM of some kind
<azonenberg>
yeah this was able to saturate ~10 Mb/s
<azonenberg>
With 10 Mbps TCK
<azonenberg>
it got close to theoretical max
<sorear>
How high does TCK go on realistic hardware?
<awygle>
rqou: fountain codes are dope af
<rqou>
ee126 ftw
<rqou>
(also hard af)
<azonenberg>
sorear: the single die 7 series parts can do 66 MHz
<azonenberg>
most other chips i've looked at top out somewhere in the 10-30 range
<pie_>
rqou, oops, that was at your jump/branch mcu dump hack thing
<rqou>
pie_: what about it?
<rqou>
i have no idea if it actually works or not
<awygle>
but no, iirc we had RS ... (8,11) or sometihng like that?
<awygle>
the Fancy Radio on the Much Better System had experimental support for LDPC which i was excited about :p
<sorear>
(per discussion about fancy jtag adapters earlier I was kind of wondering what the highest TCK you could ever reasonably want an adapter to generate is)
<rqou>
the only problem is "Raptor codes are heavily covered with patents in various jurisdictions"
<rqou>
same with LT codes
<awygle>
oh wow RS(255,239), i was way off
<azonenberg>
sorear: starshipraider's jtag master will go up to the max toggle rate on the GPIOs, most likely limited by the level shifter
<awygle>
sorear: i think the ARMs with RCLK support go to the hundreds of MHz
<azonenberg>
So 400-500 Mbps toggle rate depending on voltage level, half that (200-250 MHz) for your TCK frequency
<rqou>
also practical fountain codes are a surprisingly recent invention
<rqou>
for reference, they are newer than blue leds
<rqou>
:P
<azonenberg>
if you made a bare bones unbuffered io board you could probably hit 1 Gbps toggle rate for 500 MHz TCK, although you would likely have to rewrite the jtag core a littl ebit
<awygle>
turbo codes are cool
<awygle>
all the codes are cool
<awygle>
cooooooodes
<pie_>
^^^
* pie_
wants to learn codes
<rqou>
paaaaaaaaatents :P
<pie_>
hasnt gotten around to it
<pie_>
^^^ :C
<awygle>
azonenberg: no jtag slave is going to hit those rates tho
<sorear>
Goppa codes are deep black magic of a different sort
* pie_
is a low key information theory fanatic
<azonenberg>
awygle: thats the point though
* awygle
thinks slave is probably the wrong word
<sorear>
DUT? :p
<azonenberg>
Starshipraider is intended to speak all of these protocols faster than all known devices support
<awygle>
rqou: turbo codes are out from patent coverage now aren't they?
<azonenberg>
it's intended to be a "build once, talk to anything" platform
<azonenberg>
then just go as fast / whatever voltage as the DUT supports
<awygle>
oh hallo pointfree
<pointfree>
o/ awygle
<rqou>
azonenberg: and then you get trolled by a device that sends back a 10khz RCLK :P
<pie_>
ugh maybe my firefox choked on itself again
<awygle>
rqou: isn't RCLK ~required to be the same speed as TCK?
<rqou>
um, i don't think so?
<awygle>
hm
<rqou>
er maybe
<azonenberg>
rqou: hey, slower isnt a problem
<awygle>
i've never actually used rclk in a meaningful way
<azonenberg>
although for the short term i wont support adaptive clocking
<rqou>
as in, i thought it's supposed to tell the master to slow down its tck to match rclk
<azonenberg>
only fixed tck
<azonenberg>
rqou: yes that is the idea
<azonenberg>
But i'm not generating tck from a pll
<awygle>
i thought it was supposed to help you figure out your delays and whatnot
<azonenberg>
it's just a delay counter in my rtl
<azonenberg>
i can make it as slow as i want
<rqou>
so that e.g. your mcu running at 32khz can keep up
<awygle>
that crazy system i described above was run all over the system completely unbuffered and we eventually had to drop TCK to 100 kHz because we were getting double-clocking from crosstalk/reflections
<azonenberg>
...
<awygle>
the Much Better System has its name for a reason :p
<rqou>
did this into space?
<sorear>
what's rclk and who is responsible for it?
<rqou>
return clock
<awygle>
rqou: i don't know what you're talking about. unrelated, have i posted the explody rocket video here yet?
<sorear>
I don't think that was in the copy of 1149 I read
<rqou>
it's an extension
<rqou>
RCLK is the ARM name for this idea
<rqou>
awygle: did the crappy radio and jtag thing into space? or was it for some other purpose?