andymandias has quit [Remote host closed the connection]
andymandias has joined #glasgow
redstarcomrade has joined #glasgow
ari has quit [Ping timeout: 272 seconds]
ari has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
redstarcomrade has joined #glasgow
smeding has quit [Quit: Lost terminal]
smeding has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
coderobe has quit [Ping timeout: 272 seconds]
Wanda[cis] has joined #glasgow
<Wanda[cis]>
hmm
<Wanda[cis]>
I: g.applet.program.avr.spi: device signature: 1e 94 82 (unknown)
<Wanda[cis]>
[...]
<Wanda[cis]>
AttributeError: 'NoneType' object has no attribute 'erase_time'
<Wanda[cis]>
okay time for a detour
coderobe has joined #glasgow
<Wanda[cis]>
welp. I think I added the device properly, but unfortunately the lock bits on the device are in the nekophobic configuration
altracer[m] has joined #glasgow
<altracer[m]>
How about userspace HID input proxy? Like CMSIS-DAP v1, and there will be a queue to buffer multiple transitions
<Wanda[cis]>
... HID proxy?
jn has quit []
jn has joined #glasgow
jn has quit [Ping timeout: 244 seconds]
jn has joined #glasgow
<altracer[m]>
Wanda: I can't help you with avr other than "apply high voltage programming"
<Wanda[cis]>
does this help with lock bits?
<Wanda[cis]>
because I doubt that
<altracer[m]>
Grazfather: do you want to just patch through some FTDI MPSSE emulation, or also spin some debugger logic on Glasgow?
<Wanda[cis]>
right. speaking of JTAG on glasgow.
<Wanda[cis]>
I'd be very interested in having a better JTAG remote protocol in glasgow
<Wanda[cis]>
for my own purposes
<Wanda[cis]>
it's going to become a blocker for prjcombine at some point in reasonably near future
<Wanda[cis]>
the problem is, I have no idea what protocol to use; quite possibly the answer is "go and design one"
<Wanda[cis]>
MPSSE-over-TCP could be viable I guesssss, but also fuck FTDI
<altracer[m]>
Wanda: ATmega lock bits and boot lock bits were designed for readout protection, not bricking (as in stm32f4 rdp2), you can always full-chip erase, losing program contents
<Wanda[cis]>
one thing that's reasonably simple at least is the xilinx virtual cable protocol
<Wanda[cis]>
but ehh.
<Wanda[cis]>
also not particularly inspiring
<Wanda[cis]>
altracer[m]: the problem is that I am very specifically interested in reading out the firmware from the device I have on paw
<altracer[m]>
Wanda: then you can try glitching (voltage fault injection)
<Wanda[cis]>
yeahhh I'm considering this
<Wanda[cis]>
not quite sure how to approach it though
<Wanda[cis]>
at least I have multiple copies of this devboard, so not a big problem if I destroy one
<altracer[m]>
outsource to chinese experienced companies or DIY?
<altracer[m]>
obtain a Hextree Faultier (rp2040+crowbar mosfets), write some python, desolder filtercaps, set to bruteforce for some hours
<altracer[m]>
a Glasgow may be better and more flexible for this
<Wanda[cis]>
any idea how likely it is to destroy the AVR this way?
<altracer[m]>
they're very robust compared to 90nm cortexm
<altracer[m]>
it's not HVpp (applying 12v) but crowbar (dipping 3.3v Vdd)
vegard_e[m] has joined #glasgow
<vegard_e[m]>
having dealt with a few different ones, I think the ones I prefer are the ones that encode a sequence of «do n clocks with this tms level and this bit sequence on tdi, with optional tdo capture»
<vegard_e[m]>
tdi sequence could probably also be optional
<Wanda[cis]>
yeah, that's what I'd want as well
<Wanda[cis]>
you give either a bitvec or a const value to put on tdi, another bitvec or const for tms, and a flag whether you care about tdo
<Wanda[cis]>
that said
<Wanda[cis]>
if I was actually designing a proper remote protocol, I'd want it to be a bit more featureful
<Wanda[cis]>
at the very least: remote sleep, set/get TCK frequency
<Wanda[cis]>
also GPIO get/set for some devices
galibert[m] has joined #glasgow
<galibert[m]>
is remote sleep something else that just not changing anything?
<Wanda[cis]>
and if I was designing it with a larger scope than just glasgow, I'd really want the protocol to give you metadata about the device's capabilities and any board vendor/product IDs you have available
<Wanda[cis]>
galibert[m]: remote sleep is specifically about ensuring that the device performs the delay after previous command and before next command; when you have a protocol that supports proper batching and have a target that needs delays for some reason, it is crucial that you use the remote sleep command, and not just `usleep()` call within client code
<galibert[m]>
interesting
<galibert[m]>
you meant sleep as in "wait", not "sleep state", I understand now
<Wanda[cis]>
you don't want your delays to get fucked up because of TCP/IP network farts
<galibert[m]>
or, well, delay
<altracer[m]>
bridge/firmware delay is far more deterministic than desktop, and that's important in flash ops and resets
<Wanda[cis]>
yeah that too
<Wanda[cis]>
though if you also need to ensure a minimum delay somewhere, it gets more complicated, as you need to design a "corking" protocol where stuff doesn't start getting executed on the probe until the whole command batch is buffered
<Wanda[cis]>
and that gets annoyingly complex because now you have to think about buffer sizes
<Wanda[cis]>
Wilfried "Wonka" Klaebe: I was talking about a hypothetical remote JTAG protocol right now, not the glitching
WilfriedWonkaKla has joined #glasgow
<WilfriedWonkaKla>
it's an FPGA. one could implement the complete glitching attack in risc-v code and execute it on the glasgow itself...
<WilfriedWonkaKla>
or micropython
<altracer[m]>
pico-glitcher is implemented in rp2040 micropython, afaik
smeding has quit [Quit: Lost terminal]
smeding has joined #glasgow
<grazianom[m]>
That's HID? How would the applet communicate with it?
<grazianom[m]>
FTDI or whatever. I don't know anything. I am just proposing anything better than bit banging
<altracer[m]>
I have a Huion H1060P graphical EMR tablet (possibly running on some USB FS GD32F1), and in Linux the official app creates a uinput HID device even in absence of tablet. I can't always compile, sign and insmod Digimend hid-uclogic.ko (which works fine)
<altracer[m]>
I don't know the Python parts of Glasgow architecture, however if it connects to FX2LP bridge using only bulk endpoints and libusb, then implementing debugger interface could be done via a virtual device generated by said python parts (not writing a libfx2 hid firmware etc.)
<altracer[m]>
Consider OpenOCD and BMDA, most their backend drivers flush some command queue (sometimes with depth of 1) through write/read methods which 90% boil down to libusb1 calls and therefore kernel syscalls (10% use libgpiod or spidev userspace). I don't think they work with downstream TCP sockets like JLink server or STLink Shared server (but could be ported to)
threeflour[m] has joined #glasgow
<threeflour[m]>
It uses bulk endpoints and libusb for reading/writing to the in/out fifos
<altracer[m]>
Just 2 and 6, no dynamic configuration?
<altracer[m]>
I would not wish on anyone to write undebuggable 8051 firmware that has to speak USB HS, Composite Device, on multiple endpoints and interfaces. It's not like it has enough packet memory to do that anyways. The FX1/2/2LP appnote highlights some inflexibility.
<threeflour[m]>
I don't remember the endpoint numbering offhand. There are two bulk in and two out endpoints. I think the ones used are always the same unless more than one applet is ran simultaneously.
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
Wanda[cis] has quit [Quit: Bridge terminating on SIGTERM]
sigstoat[m] has quit [Quit: Bridge terminating on SIGTERM]
grazianom[m] has quit [Quit: Bridge terminating on SIGTERM]
whitequark[cis] has quit [Quit: Bridge terminating on SIGTERM]
galibert[m] has quit [Quit: Bridge terminating on SIGTERM]
threeflour[m] has quit [Quit: Bridge terminating on SIGTERM]
altracer[m] has quit [Quit: Bridge terminating on SIGTERM]
WilfriedWonkaKla has quit [Quit: Bridge terminating on SIGTERM]
vegard_e[m] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has joined #glasgow
dualtachyon[m] has joined #glasgow
<dualtachyon[m]>
hmm, are you the same SamIAm that made that jlink-clone unbricker?