13:51 <davebee> Struggling trying to get the JTAG working connected to a vexriscv on an ECP5. Not sure what I'm doing wrong. I've had to modify soc.add_jtagbone() to take a jtag parameter to pass to JTAGPHY(). Otherwise it assumes it is connecting to the internal JTAG fabric. I want an external connection - actually I'd be happy with any connection. Not sure how to progress. I've also had to modify openFPGALoader so it doesn't reject

13:51 <davebee> FT232H devices that don't have the iProduct field set. I'm looking at the signals on pulseview and it looks like I'm talking to the device okay, but the data coming back does not make sense.

13:51 <davebee> ~/Desktop/openFPGALoader master$ build/openFPGALoader -v -c ft232 --detect

13:51 <davebee> Jtag frequency : requested 6.00MHz -> real 6.00MHz

13:51 <davebee> JTAG init failed with: Unknown device with IDCODE: 0x08020080 (manufacturer: 0x040 (), part: 0x40 vers: 0x0

13:51 <davebee> ~/Desktop/openFPGALoader master$ build/openFPGALoader -v -c ft232 --detect

13:51 <davebee> Jtag frequency : requested 6.00MHz -> real 6.00MHz

13:51 <davebee> JTAG init failed with: Unknown device with IDCODE: 0x01004010 (manufacturer: 0x008 (), part: 0x08 vers: 0x0

14:21 <SpaceCoaster> Davebee: when I had inconsistent results it was either cabling, making sure all grounds were connected or due to powering usb devices from different power supplies.

14:22 <SpaceCoaster> I used a multiport usb hub with ample power and things improved

15:23 <davebee> Thanks. I have a powered hub driving just the FPGA board and the FTDI board, so I don't think it is power. I think I've not connected the JTAG / RISC-V parts up internally I suspect. But not sure how to progress. I've got a bus pirate on order, so I will be able to bit bang the JTAG if needed.

20:15 <tnt> _florent_: is there a doc of the liblitepci "api" ? My understanding of its requirements are that : (1) you call litepcie_dma_next_write_buffer and fill the returned buffer until it returns null (and you _have_ to fill all of them before calling dma_process()). (2) call dma_process() (3) call litepcie_dma_next_read_buffer and process the data from each buffer (and again, you _must_ do it until no buffer is available before calling dma_process() again).

20:48 <_florent_> tnt: sorry, no doc (but I started improving/cleaning up the examples today), have you looked athttps://github.com/enjoy-digital/litepcie/blob/master/litepcie/software/user/litepcie_dma_minimal_example.c?

20:49 <tnt> yeah, just looked at it. Which seems to match my understanding. But it wasn't extra clear that the "send as much data as possible" isn't just a suggestion. It's a _requirement_ for it to work properly.

20:51 <tnt> _florent_: something else that came up is that because of the modulo add and the way the buffer is filled with data in the dma_test (each buffer has the same content basically), if you get buffers getting mixed up between them, those kind of errors are not detected at all.

20:56 <_florent_> tnt: we've merged different PR recently from different developers and I want to spend some time refactoring the dma test code.

20:57 <_florent_> tnt: but litepcie_test play & record should be close to what's used on some real systems

20:58 <tnt> I fixed up the dma_test for my purposes here, but just thought I'd point it out. I now have my "back pressured" chain working in non-zero-copy mode. Still need to tweak a couple of things for the zero-copy mode, but that's probably tomorrow's problem.

21:07 <_florent_> tnt: ok good, thanks. Do you think you'll contribute your fixes? (that would be awesome :))

21:09 <tnt> _florent_: yeah, that's the hope, the question is if it'll workout from a compatibility point of view.

21:10 <_florent_> tnt: great, compatibility regarding internal changes in the DMA as we discussed previously?

21:13 <tnt> yeah. The hardware has relatively small changes that can easily be made togglable.

21:13 <tnt> The kernel driver on the other hand is diverging quite a bit.

21:21 <_florent_> tnt: ok I see. I don't necessarily have to maintain retro-compatibility for the driver (since private projects using the LitePCIe core have their own drivers), so as soon at the core stay by default retro-compatible, the driver can eventually change.

21:22 <tnt> ok good to know.

21:22 <tnt> In any case when it's working I'll publish it and ping you about it.

21:24 <_florent_> tnt: great thanks.

22:59 <swetland> Hey folks, possibly silly question... I've modified the VexRiscv core configurations inside my Litex workspace, and regenerated the verilog. How do I regenerate the Litex components that wrap them so I get the new version of the core?

23:00 <swetland> (Trying to get a U/M/S RV32IM with MMU to fit in a LFE5-25F and the standard "linux" config needs 108% of the memory resources)

23:22 <cr1901> If you modified the generated verilog in-place in the pythondata-vexriscv* repo, I would think your changes would be picked up automatically

23:24 <cr1901> Also, not that you're having an XY problem, but: linux-on-litex fits on Orangecrab/25F part without special modifications last I checked. Did this change?

23:27 <swetland> trying again without the peripherals (video framebuffer, spi flash, spi sdcard)

23:34 <swetland> okay that worked but not sure if it also picked up my 2k icache/dcache change or not.

23:34 <swetland> the video fb DMAs from sdram so it would surprise me if it needed a lot of internal memory...

23:37 <swetland> yikes. adding the vfb took it from 20/56 to 52/56 DP16KDs

23:38 <cr1901> Ahhh. I'm not sure I ever used the core w/ video

23:42 <swetland> okay changed back the icache/dcache config to see if these changes are getting picked up

23:44 <swetland> looks like

23:53 <swetland> So now my question is can I get the video framebuffer to use fewer than 32 DP16KDs. Maybe reducing the colordepth?