06:08 <jersey99> _florent_ I am having some trouble where the Litex BIOS doesn't boot when the CPU is built with uart=crossover. It only boots when I have the litex_server running. Is there some interrupt the CPU is waiting for in order to boot?

06:09 <jersey99> Note the CPU boots normally when the uart isn't being used in crossover mode

06:10 <jersey99> *the CPU only boots when I have the litex_server running AND run "litex_term crossver"

06:12 <_florent_> jersey99: With the crossover UART, the UART is indeed handling backpressure from the destination, which stalls the CPU when destination is not ready/enabled.

06:12 <_florent_> jersey99: I added this to still allow the CPU to boot in this case:

06:12 <_florent_> https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/uart.py#L281

06:13 <jersey99> Aha!

06:13 <_florent_> This adds some logic to detect this situation and flush the data

06:13 <jersey99> let me take a look. Thanks a lot!

06:13 <jersey99> That is fair

06:13 <_florent_> But you need to enable it manually since this is not necessarily wanted in all situations

06:13 <jersey99> Yes, totally makes sense!

06:14 <_florent_> I'm using it here: https://github.com/360nosc0pe/scope/blob/main/sds1104xe.py#L132

06:15 <jersey99> That's a really cool project :)

06:20 <jersey99> Have you managed to come up with a LiteLVDS? :) .. So far I have interfaced 1 LVDS adc with migen/Litex and it's not clear to me if there will ever be benefit in making something generic with this

06:20 <jersey99> _florent_

06:25 <_florent_> The ADC/DAC protocols are often a bit specific, if we see this could be useful to have a common core for this in the future we could think of it

06:26 <_florent_> paul-web: We are currently playing with hard Cortex-M on QuickFeather/TangNano4K to improve ARM support in LiteX, it would also be interesting to try the ARM softcores too and should be very similar. But we would also need to study the licenses a bit to see what can be shared...

06:33 <jersey99> sounds good

12:57 <paultech> _florent_: Good to know regarding ARM and QuickFeather/TangNano4K.

12:57 <paultech> I figured licensing would be a sticky issue - Brief review (the licensing document is surprisingly short for something like IP) seems to show if user provides the *.vp/tcl files there would be no violation.

12:57 <paultech> The documentation needed to host the CPU is openly available - https://developer.arm.com/documentation/ddi0413/d

12:57 <paultech> You may even find ARM has a positive attitude to the litex inclusion, They've stated the Cortex FPGA line M1/M3 goal in life is to be a rapid proof of concept prototyping core. Cant be better than LiteX for that ;)

12:57 <tpb> Title: Documentation – Arm Developer (at developer.arm.com)

13:55 <tnt> _florent_: Here's the horror :) https://github.com/smunaut/liteiclink/commit/0a9df04a8aeac5ad069a26ad4997ccebc3219bba

14:06 <tnt> At least it builds without fatal error. No clue if it works though.

14:22 <Wolf0> _florent_: are you interested in expanding FK33 support? I could maybe help with some things.

14:30 <paultech> How are the LiteSPI modules generated? The Arty S7 uses a S25FL128S (S25FL128SAGMFx00 according to datasheet). The datasheet shows it supports quad read but the generated module only has READ_1_1_1

14:31 <_florent_> tnt: thanks, in fact I'm sorry but I'm realizing that duplicating the code between GTHE3/GTHE4 (even if most parameters are common) could still be interesting, since it allows easy comparison with the wrapper generated by the wizard and use useful for configuration that haven't yet been yet, so I'll have to think about the best way to merge this.

14:32 <_florent_> Wolf0: yes, it would be useful to have an example design the the FK33 with SoC + PCIe + HBM

14:33 <paultech> Ah seems to come from the flashrom project files - https://github.com/flashrom/flashrom/blob/master/flashchips.c#L16174

14:35 <_florent_> Wolf0: I wanted to create a project to create FPGA accelerators with LiteX (and cores), using the Acorn, XCU1525 and FK33 as first supported boards, but haven't spent too much time on it yet

14:36 <_florent_> Wolf0: If that's something you are interested and want to help on that, we could improve the FK33 support there (LiteX-Boards is a bit too generic for this)

14:37 <_florent_> paultech: I also noticed this some time ago: https://github.com/litex-hub/litespi/issues/55

14:38 <_florent_> the generation should be improved

14:40 <paultech> Still confirming my issue but I believe what I actually wanted was 'S25FL128S0' which maps to flashroms '.name= "S25FL128S......0",' module which does seem to match the datasheet and partnumber in use.

14:40 <paultech> The CLK for SPI is incorrect in the Arty S7 platform, testing it now

14:41 <paultech> Useful information in there, thanks

14:43 <_florent_> paultech: Sorry, not sure to understand the issue

14:47 <tnt> _florent_: heh before merging it, it'd be good to check it works :)

14:49 <_florent_> tnt: yes sure, but before you spend too much time, I was just sharing my thought on this :)

14:49 <_florent_> when I need to support a new protocol, what I do generally is that I generate the wrapper with the wizard and then do a comparison of liteclink wrapper/Xilinx wrappers (the parameters are in the same order)

14:50 <_florent_> so while merging things can seem a good idea, it could also prevent this, so has advantages/disadvantages

14:52 <_florent_> I need to check if I the Ultrascale+ boards I have have GTHE4 transceivers, if so I could do a LiteICLink test

14:52 <tnt> I see. I wrote a python script that parses the wrapper generated code and unisim model to extract default values and used values and "sort them". (to find gthe3 / gthe4 differences and what's non-default, etc ...)

14:56 <tnt> Unfortunately the board I have doesn't have anything exposed on SMA :/

14:56 <tnt> I guess maybe a SFP+ transceiver and a fiber loopback would do the trick.

15:02 <paultech> https://github.com/litex-hub/litex-boards/blob/9119250276b9fd7e0a738eebf31b3e84a3a479b5/litex_boards... -> Incorrect spiflash4x.clk (don't believe you need to route a clk here?)

15:02 <paultech> https://github.com/litex-hub/litex-boards/blob/9119250276b9fd7e0a738eebf31b3e84a3a479b5/litex_boards/targets/digilent_arty_s7.py#L80 -> Uses Python module 'S25FL128S' which does not support Quad Read. The desired Python module that matches the part number is S25FL128S0 (note the trailing 0)

15:02 <paultech> I'm currently exploring litex so I may be way off but that and setting CONFIG_VOLTAGE in accordance with the XDC for the Arty S7 seems to give me working quad flash on the board

15:03 <paultech> Arty S7 does build and boot with those changes (sorry, webclient for irc is not ideal and is dropping messages. I'll jump on a proper client here shortly)

15:04 <_florent_> tnt: SFP+ transceiver + fiber loopback will work yes, I'm generally using a SFP loopback module for these tests

15:05 <_florent_> tnt: I just try to stay with copper initially since no need to handle tx_disable (with is sometimes inverted on some boards)

15:06 <_florent_> tnt: as an initial test, you can also just use the internal loopback, in the PCS, then in the PMA and once both are OK, test with the external loopback

15:07 <tnt> Yeah, I'll see if they have anything that can do loopback ... (still don't have a board locally ... ordered but it's taking forever)

15:08 <_florent_> For the test, you can use the test_prbs script here: https://github.com/enjoy-digital/liteiclink/blob/master/bench/serdes/test_prbs.py

15:08 <_florent_> (just need a UARTBone bridge to the SoC)

15:09 <_florent_> you can enable internal loopback with --loopback

15:09 <tnt> Ack, I'll dig into that and see if I can get that running.

15:11 <tnt> BTW, unrelated, but how do you suggest to handle the patch I need to litepcie to change the Quad location ? Currently I just patch my local install .xci but ideally I'd like to have a "basic" version of the ADRV2CRR-FMC platform/target put into litex-boards but obviously it would need that patched version to build.

15:13 <_florent_> tnt: we should probably do something similar to what ilia__s just did for 7-series: https://github.com/enjoy-digital/litepcie/commit/6ef3cba6ad077cda1f68090576377333d58d07bc

15:14 <_florent_> tnt: this will allow you to just generate the PHY from the tcl script/parameters

15:15 <_florent_> tnt: but before this, we have to do https://github.com/enjoy-digital/litepcie/issues/42 (or at least move the verilog code that has been integrated in the PHYs)

15:15 <tnt> Mmm ... indeed that looks like a much better solution than the pre-made xci.

15:24 <_florent_> In fact in the initial version, the initial PHY was slightly modified to expose the second QPLL from the to the user and allow it's use for other protocol, so it was not manually generated. But this is no longer used and this is generally too complex to mix PCIe and other protocol on the same Quad, so it's indeed better now to just generate PHY from the tcl.

15:24 <_florent_> I don't think doing something similar for Ultrascale will be too complicated, I could have a look when I'll have a bit more time.

15:27 <_florent_> paultech: Most of the developpers are probably using the Arty A7, so it's possible there are some issue on the Arty S7 with SPI Flash. Feel free to open LiteX-Boards issue/PR if you think you fixed some parts.

15:32 <paultech> I will do, just ensuring I don't break more than I fix. I've been around FPGA's plenty but this is my first exposure to ground-up development with them so still building my board collection.

17:29 <mithro> People might find http://www.ijmerr.com/uploadfile/2021/1117/20211117042037910.pdf interesting.