00:00 <bburky[m]> and it seems repeatable (except when it very rarely works correctly). The offset seems consistently 0x400. Do you want me to file a GitHub issue or anything?

00:01 <bburky[m]> sorry: 0x00-0xff bytes of golden and they first appear at 0x0400 of actual (I phrased it backwards)

00:02 <whitequark[cis]> fascinating, what is in the first 0x400 bytes of actual?

00:09 <bburky[m]> data and the patch I made to test: https://gist.github.com/bburky/ac39a5211eb386c2edcc73e8b29b5397

00:11 <whitequark[cis]> time for biodiff!

00:11 <whitequark[cis]> a diff that can align sequences

00:12 <bburky[m]> Data at the begining is part of the same test pattern, so not complete garbage. Perhaps (libusb?) is losing the first x bytes somehow? It would have to lose a ton of data (0x1fffe - 0x400 I think?) to land on an offset of 0x400 I think though? Very weird.

00:13 <whitequark[cis]> no, this tracks actually

00:15 <whitequark[cis]> that's 128K-2-0x400; each scheduled IN EP transfer is 32*0x200=16K, and there is at least 16 of them pipelined, which is 256K

00:15 <whitequark[cis]> but also

00:15 <whitequark[cis]> looking at biodiff

00:16 <whitequark[cis]> there's only a difference in the first 0x3fc bytes, everything afterwards is completely aligned

00:16 <whitequark[cis]> like check this out

00:17 <whitequark[cis]> this is the beginning

00:17 <whitequark[cis]> this is the end

00:17 <whitequark[cis]> everything in between matches just fine

00:17 <whitequark[cis]> it's an offset

00:18 <whitequark[cis]> oh I see what you mean

00:18 <whitequark[cis]> since it's a repeating pattern an offset is an offset by modulo

00:19 <whitequark[cis]> yeah we could probably stand to have a longer generator polynomial

00:21 <bburky[m]> yeah, that's why I called it an offset, that's what it is it seems? The USB wizardry is beyond me, so I probably won't be able to help guess what's going on at the USB/libusub level (happy to test though). The applet gateware seems to repeat forever, so if you somehow lost data, and tried to do an extra read at the end, you'd get another chunk of the pattern back, right?

00:21 <bburky[m]> A simple tweak might be to have python send the length to the fpga before starting the test, and have the fpga refuse to send more than requested?

00:22 <whitequark[cis]> yep sure

00:22 <whitequark[cis]> try using ETW tools to capture USB packets

00:23 <whitequark[cis]> i've watched Maya do this, it's kind of a pain but seems very effective, giving more information than just wireshark captures

00:26 <bburky[m]> That sounds daunting, but I'll give it a try. These seem to be the steps? https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/how-to-capture-a-usb-event-trace

00:30 <whitequark[cis]> yes

00:31 <whitequark[cis]> then this https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/viewing-etw-traces-in-netmon

01:24 <bburky[m]> I honestly have very little idea how to use this tool, but I seem to have figured out how to filter by VID/PID and managed to turn on a bunch of columns with USB info.

01:24 <bburky[m]> I'm not sure how to actually read packet contents with this tool, or I'd look for the test pattern

01:24 <bburky[m]> Perhaps the line I have highlighted is suspicious? Following this there's a ton of 0x4000 sized reads if I understand correctly. But this odd one appears before this early OUT transfer (which perhaps is setting mode.SOURCE?).

01:27 <bburky[m]> Discord appears to have compressed the image a bit. I added it to the gist too: https://gist.github.com/bburky/ac39a5211eb386c2edcc73e8b29b5397

01:43 <bburky[m]> If I comment out `iface.reset()` under `if mode == "source":` it consistently passes. I'm not sure what the reset is supposed to do, can it cause a read?

05:19 <_whitenotifier-5> [glasgow] bburky opened issue #550: `glasgow run benchmark source` fails on Windows - https://github.com/GlasgowEmbedded/glasgow/issues/550

06:08 <rcombs[m]> thinking about different methods of storing TAS data after SPI flash was suggested the other day, and realized "hey wait, isn't an SD card just a really big SPI flash with more controller features"

06:09 <rcombs[m]> I wrote off doing actual FAT stuff as impractical a while ago, but... what if I just, didn't have a filesystem

06:09 <rcombs[m]> card contains a single file at 0x0

06:13 <rcombs[m]> largest TAS I've played back is 410MB, though that compresses to a 1MB .zip so maybe the answer really is "build some actual compression ya doofus"

06:47 <josHua[m]> not sure how much throughput you need and/or how much you can cram on there, but I also wonder if SERV is fast enough to do the job of doing the filesystem for you

07:07 <whitequark[cis]> <rcombs[m]> "largest TAS I've played back is..." <- yes

07:27 <rcombs[m]> what's a SERV

07:28 <josHua[m]> SERV is Olof Kindgren's ultra tiny RISC-V soft core

08:46 <ewenmcneill[m]> SERV: https://github.com/olofk/serv (it's a very slow, but very tiny, "basic microcontroller" level RISC-V CPU)

09:15 <ari> wasn't there already some applet that implemented a tiny mips-like core?

10:45 <voltagex[m]> it'd be really good to have the keyed plastic bit and then break out to other stuff rather than fiddly individual jumper wires

10:48 <voltagex[m]> *thank you*. I never knew this existed! (There's a tcpdump equivalent that I've used but never this!)

14:41 <davidrysk[m]> whitequark: https://review.openocd.org/c/openocd/+/8191 I was asked to review this, can you take a look? (change in sleep command in OpenOCD remote_bitbang)

14:41 <davidrysk[m]> Asking since it may affect glasgow

16:23 <whitequark[m]> david.rysk (@_discord_169816341568684032:catircservices.org) yeah lgtm!

17:36 <davidrysk[m]> thanks!

21:22 <_whitenotifier-5> [glasgow] neuschaefer synchronize pull request #549: applet.interface.jtag_openocd: implement remote sleep - https://github.com/GlasgowEmbedded/glasgow/pull/549