00:06 <CarlFK> bunnie: https://github.com/AlphamaxMedia/netv2mvp-scripts "compile your own version of openocd to work with NeTV2. The mainline openocd has a bug in the bcm2835 driver"

00:06 <tpb> Title: GitHub - AlphamaxMedia/netv2mvp-scripts: Various scripts for NeTV2MVP (at github.com)

00:06 <CarlFK> that was 2 years ago - is it still needed?

12:24 <bunnie> <CarlFK "that was 2 years ago - is it sti"> I think they have finally absorbed the patch to deal with the drive strength issue on the drivers

12:25 <bunnie> however, I have not tried a mainline openocd on the boards yet. what you'll see is when you go to do a firmware update, it'll stall because you get random bit corruption due to the signal integrity being terrible from the drive strength being wrong

12:26 <bunnie> the patch I had tunes that. ideally, this would be the sort of thing you could specify as an argument to openocd but I tried doing a PR to them once and...let's just say it's not a welcoming crowd.

17:45 <somlo> daveshah: after updating to yosys fa8cb3e (the latest upstream), when I try to build LiteX for 5g-versa or trellisboard, I get an error like this: https://pastebin.com/NQjcNXkQ

17:45 <tpb> Title: ERROR: Found error in internal cell \top.$auto$alumacc.cc:485:replace_alu$53097. - Pastebin.com (at pastebin.com)

17:45 <daveshah> somlo: this is a known regression unfortuntely, see https://github.com/YosysHQ/yosys/issues/2058

17:45 <tpb> Title: Fix 0-WIDTH wire handling in techmap rules. · Issue #2058 · YosysHQ/yosys · GitHub (at github.com)

17:47 <somlo> ok, I'll start watching that issue, and rebuild yosys with the last commit before the regression, for now... Thanks!

18:38 <dkozel> Has anyone done data streaming over USB on the IceBreaker board with LiteX? esden tnt ?

19:01 <CarlFK> bunnie: "argument to openocd but I tried doing a PR" ... URL to PR? maybe I can get that patched in the debian version

19:06 <CarlFK> http://openocd.zylin.com/#/c/4721/ work around bcm2835 gpio hardware synchronization bug

19:06 <tpb> Title: Gerrit Code Review (at openocd.zylin.com)

19:10 <bunnie> ah right, that reminds me now exactly the issue. It wasn't a drive strength problem, it was a problem with the way the BCM2835 synchronizes reads across clock domains

19:10 <bunnie> you'd lose reads occasionally the way it implemented at the time

19:11 <bunnie> I think this was actually fixed, they eventually took some other approach to creating a read barrier across the clock crossing

19:11 <bunnie> not by my PR but someone else went through the trouble of pushing it

19:25 <CarlFK> I have v 0.10.0 on a pi4 + netv2 - is this worth trying?

19:25 <CarlFK> v 0.10.0 from http://raspbian.raspberrypi.org/raspbian buster/main armhf

19:25 <tpb> Title: Index of /raspbian (at raspbian.raspberrypi.org)