09:04 <avis> Hello, I've recently been trying to run a bitstream through openocd for my xilinx lx9; impact software is no longer a choice on my new os; my interface is a USB that connects with a JTAG embedded on the microprocessor of my board

09:05 <avis> I tried openocd, however the loaded config files could not support my adapter

09:09 <avis> PaulFertser: I managed to adapt some parts of iCEBURN to communicate to spi; I was using the wrong interface before; the spi protocols were different, though; one interface (0x84) was reserved as a cmdout stream, which returned spi_speed after it was reset on an ice lattice; this is not the case with my fpga, I have to pass a getSpeed protocol through the cmdin interface, and read from cmdout.

09:10 <avis> the width was different too; the code uses two bytes for spi communication, xilinx uses 4, with the last one being port-num

10:34 <zapb_> PaulFertser, Gerrit is "down" / unavailable again

10:41 <PaulFertser> zapb_: guess I caught something this time

10:55 <PaulFertser> zapb_: it looks like some aggressing crawling make gitweb.cgi perl script take too much CPU to slow everything down.

10:56 <PaulFertser> zapb_: it might be worth considering getting Jenkins on its own host too because every now and then it does use all iotime it seems, even though I tweaked the priorities and changed the i/o scheduler to "none" which improved the things a lot.

10:59 <PaulFertser> It's surprising how seemingly inconsistent the behaviour of this server is :/

11:00 <PaulFertser> It's like every time I start looking at it nothing is wrong.

11:16 <zapb_> PaulFertser, what it this gitweb.cgi Perl script? :D

11:18 <PaulFertser> zapb_: just a web interface to git with syntax highlight etc, it's like cgit.

11:19 <PaulFertser> zapb_: btw, another interesting related feature is autogrouping which is enabled in Linux by default (but disabled by Debian patch). It makes "nice" levels essentially not do anything at all for server workloads.

11:19 <zapb_> PaulFertser, is this Perl script part of Gerrit?

11:20 <PaulFertser> zapb_: no, but Gerrit has integration for it.

11:21 <zapb_> PaulFertser, and we use it with Gerrit? Sorry for the questions but I never noticed that we have something like cgit

11:21 <PaulFertser> zapb_: https://review.openocd.org/gitweb?p=openocd.git;a=summary

11:22 <PaulFertser> zapb_: it's good you're asking, makes me think more about why and how we need it if at all.

11:22 <zapb_> PaulFertser, oh wow :D

11:23 <zapb_> PaulFertser, tbh, I always thought that https://review.openocd.org/openocd.git is served by Gerrit

11:23 <zapb_> Never opened it with a browser :D

11:23 <PaulFertser> :D

11:24 <PaulFertser> It is, there's "jgit" server integrated. But there's also that gitweb and I can see how it can suddenly have many threads all at once working against our latency goals for the Gerrit web interface itself.

11:24 <zapb_> Okay, and it knows by login :D

11:25 <zapb_> s/by/my

11:26 <zapb_> PaulFertser, anyway, my general point is that a project like OpenOCD cannot have a uptime much worse than my private GitLab instance ;D

11:27 <PaulFertser> zapb_: it shouldn't, yes.

12:06 <PaulFertser> I'll restart Gerrit in 5 minutes if nobody minds. Want to see if 5 httpd worker threads (instead of 25 which is default) is reasonable.

12:10 <zapb_> PaulFertser, thanks!

12:16 <PaulFertser> One would have guess it's possible to reliably have high-priority tasks running on Linux by now without too much effort or guessing, with the kernel not allowing it to slow down to a crawl.

12:19 <PaulFertser> Restarted, let's see how it goes.

12:19 <PaulFertser> I might just disable internal gitweb later and run cgit with low priority instead.

12:59 <zapb_> thanks!

13:00 <PaulFertser> BTW, OpenOCD pipe users might want to review my https://review.openocd.org/c/openocd/+/8222?usp=search

13:01 <PaulFertser> Also I wonder what to do with lpc55xx support. It does the job it was made for but proper testing for enhancements I won't be able to do, I only had hardware remotely, it might or might not work to get access to it again. https://review.openocd.org/c/openocd/+/8189?usp=search

15:08 <avis> hey Paul if you're still there, could you just go over, one more time, what you said yesterday about the spi flash

15:12 <PaulFertser> avis: hey!

15:12 <PaulFertser> avis: so you have some progress with that python code? Good to hear!

15:13 <PaulFertser> avis: what I was saying is that most SPI NOR flash devices talk a protocol very similar to what was documented in "m25p80" datasheet. In your case you have the board in your hands, right, you can check what flash IC specifically is used there and read its specific datasheet instead.

15:15 <avis> I would find the identifier on the board?

15:17 <PaulFertser> avis: it's called "chip markings" and it's laser-etched on plastic package that contains the flash memory.

15:18 <PaulFertser> avis: or you can also take a look at board schematics.

15:35 <avis> on original file you sent me, it seems that it is a micron flash: 128 Mb Micron Multi-I/O SPI Flash

15:35 <avis> but I wasn't able to find it through searching the ids on the nor flash ic

15:37 <PaulFertser> avis: do you see the flash IC physically? Can you read the markings on it?

15:37 <PaulFertser> Or probably share a photo with res high enough? imgbb is recommended for sharing photos

15:39 <avis> yeah the markings are hard to read

15:40 <PaulFertser> If you get far enough in the protocol you can also read the JEDEC ID with software over USB.

15:40 <PaulFertser> The command to read JEDEC ID is the same for all parts.

15:40 <avis> this page specifies it: https://www.avnet.com/opasdata/d120001/medias/docus/7/AES-S6MB-LX9-G-User-Guide-Configuration-Guide-IDS-13_2.pdf

15:41 <avis> so what is it I'm trying to do with the flash?

15:41 <PaulFertser> Get read access to it, then get write access to it.

15:41 <avis> my ultimate hope is to bitbag jtag or interact with jtag directly (embedded) over usb, and send a bit stream over to it

15:41 <PaulFertser> I assume the flash contains the bitstream for your FPGA.

15:42 <PaulFertser> I assume you do not need JTAG to change bitstream for your FPGA.

15:42 <avis> jtag's not necessary for sending a bitstream?

15:43 <PaulFertser> JTAG is just a transport. If you can write to the flash directly by other means and writing to the flash is all you need then JTAG is not necessary.

15:44 <avis> So now with the nor memory in mind, what do I do next?

15:45 <PaulFertser> avis: you're doing FPGA development, right? Or why are you talking about uploading the bitstream? I am not familiar with your specific FPGA so do not know all the details about what might be needed to work with it. And what kind of work anyway you have in mind?

15:46 <avis> Well, I want to encode an ISA with verilog, synthesize it, and run it on fpga

15:47 <avis> I'd also like to blink the led that's on here somehow; I always figured that a bitstream was necessary to be sent to the jtag to do it

15:55 <PaulFertser> I like the end goal. How do you plan to convert Verilog to bitstream?

15:58 <avis> through xilinx binaries; synthesis is done through xvf, so is mapping, then conversion

15:59 <PaulFertser> OK

16:00 <PaulFertser> So you're reading the datasheet for the FPGA in question and does it say anything about the bitstream location? Is it stored inside the FPGA or the external flash memory?

16:00 <avis> I'd think it'd work on the FPGA itself.

16:00 <avis> You need to specify pins on a constraints file, etc.

16:00 <PaulFertser> I'm asking about the permanent storage location, not where it applies to.

16:01 <avis> mm, probably flash then

16:03 <PaulFertser> Then I'd guess having access to flash anyhow is enough and you do not need JTAG for that.

16:05 <avis> so I can just send the contents of a bit file over to flash?

16:05 <avis> over the 'write' interface?

16:06 <avis> I guess it is through flash, it says here: Use the Digilent sfutil.exe command line application to program the Flash directly through the AT90USB162.

16:06 <avis> Please see TBD for an application note on this subject

16:07 <PaulFertser> Looks like it

16:08 <PaulFertser> Probably there's more info on similar (same model/family) FPGAs you can find elsewhere.

16:58 <borneoa___> PaulFertser: just reviewed your 8222. Sorry for late check, I'm running out of spare time to follow all the patches. For 8189 I would prefer someone else to review it, I don't check the flash subsystem since ages

17:01 <PaulFertser> borneoa___: thank you! Sorry for nagging.

17:01 <PaulFertser> The patch was prompted here by some real life confusion which was non-trivial to understand even for me.

22:07 <zapb_> PaulFertser, I think I have an LPC55xx to test, I'll try to test your code. Feel free to ping me and nag :D