00:43 <somlo> so, on the trellisboard, I get a similar crash right before the login prompt: http://mirror.ini.cmu.edu/litex/fed_trellis_1.log

00:44 <somlo> so doubling the available RAM didn't fix the problem -- I'm beginning to think there's a bona fide bug somewhere... :)

14:31 <tnt> Has anyone ever had erratic pcie bandwidth after a dynamic reload ?

14:32 <tnt> Like, if the FPGA is configured directly before the machine boots, it works fine and I get stable / uniform PCIe DMA bandwidth. But if I do a bitstream reload and then re-detect the card, it "works" as in, I can see the card and do CSR and even DMA, but the bandwidth is erratic leading to data loss.

14:32 <tnt> If I then reboot (not touching the fpga), then all is well again.

14:34 <tnt> (And I'm not even close to the max pcie bw. In "good times", I can get 30Gbit/s with not overflows/oss. Here I'm just trying to get about 7Gbit/s)

14:41 <trabucayre> maybe it's stupid: the controler's driver isn't correctly reconfigured after boot ?

14:43 <tnt> I do a rmmod / force device remove / rescan / insmod after I reloaded the fpga.

14:48 <tnt> https://pastebin.com/7kiQEqEc

14:48 <tpb> Title: --- dev-bad.txt 2022-09-26 17:24:28.539974891 +0300+++ dev-good.txt 2022-09-26 - Pastebin.com (at pastebin.com)

14:48 <tnt> This is a diff of a lspci -vv of the device in the 'bad' case, vs the 'good' case.

14:49 <trabucayre> maybe a driver can't be unloaded because it's used by another card?

14:49 <trabucayre> dmesg ?

14:50 <tnt> No, the rmmod / insmod cycles works fine.

14:52 <trabucayre> for all related drivers I suppose?

14:53 <tnt> There is only litepcie.ko

14:53 <trabucayre> I talk about MB drivers :)

14:53 <tnt> Also if I do my 'rmmod litepcie; echo 1 > .../remove; echo 1 > rescan; insmod litepcie.ko' without FPGA reload, it works fine.

14:53 <tnt> MB drivers ?

14:54 <trabucayre> motherboard

14:54 <trabucayre> ie PCIe controler

14:54 <tnt> I can't remove the PCIe driver ...

14:54 <tnt> the system would stop working

14:54 <trabucayre> yes it's true :)

14:54 <tnt> it's kind of needed for ... the rest of the machine.

14:55 <trabucayre> but the question is: maybe something is done at boot time and not at rescan time?

14:55 <tnt> Also worth nothing on a different system (same fpga board but different cpu/motherboard), this stuff works just fine.

14:55 <tnt> Well maybe ... but the question is "what" ?

15:03 <trabucayre> seems to have specifics functions related to rescan... Maybe not implemented by one of drivers

15:04 <trabucayre> but maybe i'm just totally wrong...

15:05 <trabucayre> or a controler already configured by the bios and not touched by linux

15:08 <tnt> In the lspci comparison above, 'Cache line' config was missing for the 'bad' case, so I tried setpci -s 01:00.0 CACHE_LINE_SIZE=10 now, it does report it like in the 'good case' but no improvements, bandwidth is still erratic.

15:12 <trabucayre> seems my assumption is wrong

18:28 <minute> i'm confused as to how litespi flash is supposed to be used. in my soc target there is self.add_spi_flash(mode="4x", module=W25Q128JV(Codes.READ_1_1_4), rate="1:1", with_master=True). but litex_json2dts_linux.py doesn't pick this up, it's not showing up in DTS. i also don't have any commands to interact with the flash in litex bios. what am i missing?

18:29 <minute> the generated csr.csv has spiflash_core and spiflash_phy. but litex_json2dts_linux is looking for "if "spiflash" in d["csr_bases"]:"

18:31 <minute> ah, this issue is open since a year https://github.com/litex-hub/linux-on-litex-vexriscv/issues/235#issuecomment-925860844

18:34 <minute> _florent_: is there any recipe/example of how to write to spi flash on current litex?

19:14 <minute> trying to port this into bios https://github.com/litex-hub/litespi/issues/52#issuecomment-890787356

19:17 <cr1901> >LiteSPI doesn't have bitbang registers, @xobs code is for litex.soc.cores.spi_flash. <-- ahhh, a looong while back, I wrote code for litex to flash new firmware via xmodem and SPI bitbang. But it never got merged

19:17 <cr1901> (and presumably LiteSPI is how everything's done nowadays)

19:40 <minute> ok, writing to flash appears to work now

20:28 <slagernate> Hi gatecat --I tried again the picorv32 cpu on the lattice crosslinknx evn board, this time using the LSE synthesis tool w/ the radiant toolchain (the synplify pro synthsis tool was giving me the "E: mal-formed command line" error (see logs after 2022/9/16)). Sadly, litex_term is still hanging for me, so I don't think this is an OSS tool issue.

20:28 <slagernate> This time I'm using Ubuntu 20.02. (for context, previously you said: "slagernate: unfortunately, this seems like it's probably a problem somewhere in the oss stack - testing with the evn board radiant works but oxide doesn't").

20:29 <slagernate> On 9/16, I messaged the following:

20:29 <slagernate> I can't seem to get the software/demo working on a crosslink-nx eval board. litex_term is hanging when I try to upload anything. Same behaviour when I try e.g. the wishbone tool on this [icebreaker-litex tutorial](https://github.com/icebreaker-fpga/icebreaker-litex-examples) (although at least in this case I am getting `screen /dev/ttyUSB1 115200`

20:29 <slagernate> 10:00 <slagernate> to work. Can someone share or point me to an example crosslinknx setup? Kind of disappointed how difficult this has been.. was getting similar errors as this closed issue, https://github.com/enjoy-digital/litex/issues/814, which took a while to overcome.