06:24 <Melkhior> Hello, NuBusFPGA V1.2 has landed, now giving credit where credit is due: https://github.com/rdolbeau/NuBusFPGA/blob/master/Pictures/NuBusFPGA_V1_2.jpg :-)

08:58 <_florent_> minute: Thanks for reporting the issue on OHCI, I'll already integrated the workaround and will have a closer look at the real issue in the next days since I need to build some Linux SoCs.

08:59 <_florent_> somlo: Thanks for the STLV7325 PR, as discussed in the issue, I'm just wondering if the changes are important or not between the revisions, if not, we could eventually try to support revisions in the platforms/targets as we are doing for other boards.

09:00 <_florent_> Melkhior: Nice! Thanks.

11:44 <somlo> _florent_: I'm working on updating it to match the latest changes to the original version (lots of modifications to the platform file)

11:44 <somlo> once they're as close to each other as I can get them, I'll let you run diff and decide if it's worth combining or keeping separate :)

11:55 <minute> _florent_: cool! we're shipping some RKX7s now so i was re-trying everything again

11:55 <minute> _florent_: ddr3 rate is still tied to cpu mhz, right?

13:49 <minute> some more questions: linux-on-litex-vexriscv mentions spi flash to be accessible via /dev/mtd*, but that is not so... presumably something needs to be added to the DTS

13:49 <minute> and: even if i can p+r 16 vexrsicv cores, linux and opensbi only recognize (or have IDs) for 8 HARTs. what is the right place to increase this limit?

16:02 <minute> ah, litex_json2dts_linux.py looks for "spiflash" in d["csr_bases"], but that's not a thing (anymore), there's spiflash_core and spiflash_phy

16:42 <minute> ah so i'm hitting the same problem now https://github.com/litex-hub/linux-on-litex-vexriscv/issues/235#issuecomment-925860844

16:42 <minute> _florent_: i suspect there's no updated linux driver for spi flash with litespi?

16:51 <_florent_> somlo: ok good, if boards are totally different, I'm fine with a v2 platform/target

16:52 <_florent_> minute: yes, ddr3 rate is still related to cpu freq (1:4 ratio on Kintex7)

16:53 <_florent_> minute: For the number of HARTs with opensbi, that's probably here:

16:53 <_florent_> https://github.com/litex-hub/opensbi/blob/0.8-linux-on-litex-vexriscv/platform/litex/vexriscv/platform.c#L21

16:53 <_florent_> to recompile: https://github.com/litex-hub/linux-on-litex-vexriscv#-generating-the-opensbi-binary-optional

16:54 <_florent_> Not sure I tested spiflash recently...

16:55 <minute> _florent_: thanks

16:56 <minute> _florent_: is the "litex,spiflash" driver meant for "spiflash_core", "spiflash_phy" or do i have to use a different driver nowadays?

16:57 <_florent_> NLNet is going to help funding the development of hardware CI tests (in complement of the current simulation in CI), I'm planning to have a Linux-on-LiteX-VexRiscv hardware CI test, so this will help catching these kind of regression

16:58 <_florent_> somlo: While doing this, I'm also planning to automatically test Linux-LiteX-Rocket on hardware, this will avoid some tests on your side :)

16:59 <_florent_> minute: that's possible it was for the spiflash core that was used before switching to LiteSPI on targets

17:00 <_florent_> minute: and this core has probably been remove from litex repo since was no longer used in boards

17:02 <minute> _florent_: oh nice @ CI!

17:02 <_florent_> minute: so we should probably remove spiflash support from the Linux-on-LiteX-Vexriscv README until someone look at it

20:03 <cr1901> Is there a litescope verilog core generator, like how there's lite*_gen.exe for dram, eth, pcie, etc?