| *** tpb <[email protected]> has joined #litex | 00:00 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 265 seconds) | 00:05 | |
| *** Degi <[email protected]> has joined #litex | 00:21 | |
| *** amstan <amstan!~amstan@2001:470:69fc:105::1e9> has quit IRC (Quit: Reconnecting) | 01:29 | |
| *** amstan <amstan!~amstan@2001:470:69fc:105::1e9> has joined #litex | 01:29 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 265 seconds) | 01:59 | |
| *** Degi <[email protected]> has joined #litex | 02:01 | |
| *** paul-web <paul-web!~paul-web@2600:6c5d:4f00:5a24:6108:35a8:6070:2140> has quit IRC (Quit: Client closed) | 03:20 | |
| *** linear_cannon <[email protected]> has quit IRC (Quit: linear_cannon) | 04:17 | |
| 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:08 |
|---|---|---|
| jersey99 | Note the CPU boots normally when the uart isn't being used in crossover mode | 06:09 |
| jersey99 | *the CPU only boots when I have the litex_server running AND run "litex_term crossver" | 06:10 |
| _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:12 |
| 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:13 |
| _florent_ | I'm using it here: https://github.com/360nosc0pe/scope/blob/main/sds1104xe.py#L132 | 06:14 |
| jersey99 | That's a really cool project :) | 06:15 |
| 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:20 |
| _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:25 |
| _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:26 |
| jersey99 | sounds good | 06:33 |
| *** Martoni <Martoni!~Martoni@2a03:d604:103:600:2ad2:44ff:fe23:2f72> has joined #litex | 06:57 | |
| *** FabM <FabM!~FabM@2a03:d604:103:600:3b71:8838:6e52:d480> has joined #litex | 07:05 | |
| *** Martoni <Martoni!~Martoni@2a03:d604:103:600:2ad2:44ff:fe23:2f72> has quit IRC (Ping timeout: 268 seconds) | 07:06 | |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 10:02 | |
| *** TMM_ <[email protected]> has joined #litex | 10:02 | |
| *** essele_ <[email protected]> has quit IRC (Read error: Connection reset by peer) | 10:19 | |
| *** essele <[email protected]> has joined #litex | 10:19 | |
| *** jersey99 <[email protected]> has quit IRC (Ping timeout: 256 seconds) | 10:22 | |
| *** paultech <paultech!~paultech@2600:6c5d:4f00:5a24:f5b9:43b3:be85:ec4d> has joined #litex | 12:49 | |
| 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) | 12:57 |
| tnt | _florent_: Here's the horror :) https://github.com/smunaut/liteiclink/commit/0a9df04a8aeac5ad069a26ad4997ccebc3219bba | 13:55 |
| tnt | At least it builds without fatal error. No clue if it works though. | 14:06 |
| Wolf0 | _florent_: are you interested in expanding FK33 support? I could maybe help with some things. | 14:22 |
| 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:30 |
| _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:31 |
| _florent_ | Wolf0: yes, it would be useful to have an example design the the FK33 with SoC + PCIe + HBM | 14:32 |
| paultech | Ah seems to come from the flashrom project files - https://github.com/flashrom/flashrom/blob/master/flashchips.c#L16174 | 14:33 |
| _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:35 |
| _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:36 |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 14:37 | |
| *** TMM_ <[email protected]> has joined #litex | 14:37 | |
| _florent_ | paultech: I also noticed this some time ago: https://github.com/litex-hub/litespi/issues/55 | 14:37 |
| _florent_ | the generation should be improved | 14:38 |
| 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:40 |
| paultech | Useful information in there, thanks | 14:41 |
| _florent_ | paultech: Sorry, not sure to understand the issue | 14:43 |
| *** paultech <paultech!~paultech@2600:6c5d:4f00:5a24:f5b9:43b3:be85:ec4d> has quit IRC (Quit: Client closed) | 14:46 | |
| tnt | _florent_: heh before merging it, it'd be good to check it works :) | 14:47 |
| _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:49 |
| _florent_ | so while merging things can seem a good idea, it could also prevent this, so has advantages/disadvantages | 14:50 |
| _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:52 |
| 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. | 14:56 |
| *** paultech <paultech!~paultech@2600:6c5d:4f00:5a24:f5b9:43b3:be85:ec4d> has joined #litex | 15:00 | |
| 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:02 |
| 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:03 |
| _florent_ | tnt: SFP+ transceiver + fiber loopback will work yes, I'm generally using a SFP loopback module for these tests | 15:04 |
| _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:05 |
| _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:06 |
| 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:07 |
| _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:08 |
| _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:09 |
| 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:11 |
| _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:13 |
| _florent_ | tnt: this will allow you to just generate the PHY from the tcl script/parameters | 15:14 |
| _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:15 |
| _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:24 |
| _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:27 |
| 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. | 15:32 |
| *** paultech <paultech!~paultech@2600:6c5d:4f00:5a24:f5b9:43b3:be85:ec4d> has quit IRC (Quit: Client closed) | 15:42 | |
| *** paultech <paultech!~paultech@2600:6c5d:4f00:5a24:f5b9:43b3:be85:ec4d> has joined #litex | 15:44 | |
| *** paultech <paultech!~paultech@2600:6c5d:4f00:5a24:f5b9:43b3:be85:ec4d> has quit IRC (Client Quit) | 15:45 | |
| *** Martoni42 <Martoni42!~Martoni@2a03:d604:103:600:2ad2:44ff:fe23:2f72> has joined #litex | 16:07 | |
| *** Martoni42 <Martoni42!~Martoni@2a03:d604:103:600:2ad2:44ff:fe23:2f72> has quit IRC (Ping timeout: 240 seconds) | 16:13 | |
| mithro | People might find http://www.ijmerr.com/uploadfile/2021/1117/20211117042037910.pdf interesting. | 17:29 |
| *** jersey99 <[email protected]> has joined #litex | 17:41 | |
| *** MoeIcenowy <[email protected]> has joined #litex | 18:24 | |
| *** key2 <[email protected]> has quit IRC (Read error: Connection reset by peer) | 18:28 | |
| *** key2 <[email protected]> has joined #litex | 18:29 | |
| *** rektide <[email protected]> has joined #litex | 20:10 | |
| *** rektide_ <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 20:14 | |
| *** rlittl01 <[email protected]> has quit IRC (Read error: Connection reset by peer) | 21:25 | |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Ping timeout: 240 seconds) | 21:34 | |
| *** jersey99 <[email protected]> has quit IRC (Quit: Client closed) | 21:50 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!