<mtrbot-ml>
[mattermost] <sb10q> @astro I just tried the latest code on zc706 and it froze after "memtest phase 0 (status: Normal)". I commented out the ddr.memtest() call and it crashed with "Eth on Panic: panicked at 'alloc_error', src/main.rs:219:5"
<mtrbot-ml>
[mattermost] <sb10q> this SRST signal is more questionable ARM design. JTAG could send the reset command just fine, this additional GPIO is definitely not required
<whitequark>
sb: the reason SRST is a thing is low power modes where JTAG is not powered/clocked
<mtrbot-ml>
[mattermost] <sb10q> in that case, they should have made it a "JTAG enable" pin that can be tied low with a jumper or other hardware, when you don't care about power but you do care about not wasting your time with FTDI GPIO
<whitequark>
well, you don't need to waste your time with FTDI GPIO by getting a JTAG adapter that isn't a piece of shit if you weren't too cheap to do it
<mtrbot-ml>
[mattermost] <sb10q> all xilinx boards come with that
<mtrbot-ml>
[mattermost] <sb10q> built-in
<whitequark>
ok, if xilinx wasn't too cheap to do it
<whitequark>
they *definitely* can afford a decent JTAG adapter on their boards.
<mtrbot-ml>
[mattermost] <sb10q> also, amusingly on thermostat the fancier ST-Link cable crashes after a few hours/days, while the cheap Olimex FTDI thing is stable
<mtrbot-ml>
[mattermost] <sb10q> so it's not as simple as how expensive the JTAG probe is
<whitequark>
yes, most JTAG ones are awful. it was amusing to read that some things glasgow can do with a few lines of code are something you only get in multiple ten thousand dollar range JTAG adapters (things like JTAG-over-JTAG)
<whitequark>
most JTAG probes*
<Dar1us>
"JTAG over JTAG"
<Dar1us>
aieee
<whitequark>
Dar1us: what about "DDR over JTAG"
* Dar1us
gets the mind bleach
<whitequark>
that's disturbingly common, you've probably used a board that had that done to it
<whitequark>
none of these strictly *require* an advanced adapter, but multigigabyte test vectors tend to cause... issues
<Dar1us>
thankfully we only deal with toy hardware that avoids such insanities
<Dar1us>
whitequark: so.. DDR over JTAG is for testing the DDR interface, or something else?
<whitequark>
basically yes
<whitequark>
you can only read or write a few bytes this time before test vectors cross into the range of "this needs a dedicated hard drive to store"
<whitequark>
s/this/at a/
<Dar1us>
just plug a USB HD into it of course
* Dar1us
ducks
<whitequark>
"this needs the JTAG probe to use a filesystem that isn't FAT32"
<whitequark>
is this better
<Dar1us>
hehe
<Dar1us>
maybe it could use FAT32 with multipart RAR!
<whitequark>
there's also the problem that boundary scan becomes the rate limiting step of your manufacturing process
<Dar1us>
oof
<Dar1us>
multi-lane JTAG? :)
<whitequark>
i remember someone in a channel i was in suggesting "quad JTAG", you know, like quad SPI flash.
<whitequark>
you could do DDR JTAG too. actually someone patented that.
<Dar1us>
I guess the problem is going to be having to pay twice for each pin since you need one for in and one for out :-/
<whitequark>
but honestly the suggestion i loved the most was taking advantage of the lower bandwidth of TMS to encode it in a subcarrier, you know, like NTSC and colorburst. then you could have single wire JTAG pretty easily.
<whitequark>
"adjusting the hue knob on my JTAG probe" "never the same capture" "something wrong with your IR bursts?"
<Dar1us>
hah
<Dar1us>
isn't the MSP430 2 wire basically encoded JTAG?
<whitequark>
i implemented that, it's basically TDMA JTAG