| *** tpb <[email protected]> has joined #litex | 00:00 | |
| *** NotHet <[email protected]> has joined #litex | 00:17 | |
| *** lexano <lexano!~lexano@cpe00e06722f0e4-cm98524a70e35e.cpe.net.cable.rogers.com> has joined #litex | 00:24 | |
| *** lexano <lexano!~lexano@cpe00e06722f0e4-cm98524a70e35e.cpe.net.cable.rogers.com> has quit IRC (Remote host closed the connection) | 00:56 | |
| *** linear_cannon <[email protected]> has quit IRC (Quit: linear_cannon) | 01:37 | |
| *** linear_cannon <[email protected]> has joined #litex | 01:49 | |
| *** Degi_ <[email protected]> has joined #litex | 02:51 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 02:53 | |
| *** Degi_ is now known as Degi | 02:53 | |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has quit IRC (Quit: Connection reset by peep) | 03:43 | |
| *** NotHet <[email protected]> has quit IRC (Ping timeout: 250 seconds) | 03:47 | |
| *** NotHet <[email protected]> has joined #litex | 03:55 | |
| *** NotHet <[email protected]> has quit IRC (Client Quit) | 03:55 | |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has joined #litex | 04:01 | |
| *** Guest7846 <[email protected]> has joined #litex | 04:13 | |
| Guest7846 | ERROR:SoCBusHandler:Region overlap between ethmac and csr: | 04:19 |
|---|---|---|
| Guest7846 | ERROR:SoCBusHandler:Origin: 0x00000000, Size: 0x00002000, Mode: RW, Cached: False Linker: False | 04:19 |
| Guest7846 | ERROR:SoCBusHandler:Origin: 0x00000000, Size: 0x00010000, Mode: RW, Cached: False Linker: False | 04:19 |
| Guest7846 | Sorry .. Have any of you seen this error for cpu-type set to None? | 04:20 |
| Guest7846 | This has just started to happen after I pulled the latest from Litex | 04:20 |
| *** andresmanelli <andresmanelli!~andresman@2a01:cb19:8c36:4900:3822:311c:ffc8:8d2> has joined #litex | 06:08 | |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has quit IRC (*.net *.split) | 06:34 | |
| *** linear_cannon <[email protected]> has quit IRC (*.net *.split) | 06:34 | |
| *** zjason <[email protected]> has quit IRC (*.net *.split) | 06:34 | |
| *** shorne <[email protected]> has quit IRC (*.net *.split) | 06:34 | |
| *** tpw_rules <[email protected]> has quit IRC (*.net *.split) | 06:34 | |
| *** awordnot <awordnot!~awordnot@user/awordnot> has quit IRC (*.net *.split) | 06:34 | |
| *** RaYmAn <[email protected]> has quit IRC (*.net *.split) | 06:34 | |
| *** andresmanelli <andresmanelli!~andresman@2a01:cb19:8c36:4900:3822:311c:ffc8:8d2> has quit IRC (Ping timeout: 268 seconds) | 06:39 | |
| *** andresmanelli <[email protected]> has joined #litex | 06:47 | |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has joined #litex | 06:56 | |
| *** linear_cannon <[email protected]> has joined #litex | 06:56 | |
| *** zjason <[email protected]> has joined #litex | 06:56 | |
| *** shorne <[email protected]> has joined #litex | 06:56 | |
| *** tpw_rules <[email protected]> has joined #litex | 06:56 | |
| *** awordnot <awordnot!~awordnot@user/awordnot> has joined #litex | 06:56 | |
| *** RaYmAn <[email protected]> has joined #litex | 06:56 | |
| *** FabM <[email protected]> has joined #litex | 07:03 | |
| _florent_ | tnt: Great for the DDR4, I can double check the PCIe if you want. | 07:04 |
| _florent_ | Guest7846: I just pushed a workaround for --cpu-type --with-ethernet with: https://github.com/enjoy-digital/litex/commit/a489dadfbc2a63cd6db48db6d0112f4a1845dff3 | 07:04 |
| _florent_ | --cpu-type=None | 07:05 |
| _florent_ | this case is a bit particular, I should spend some time improving it | 07:05 |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 07:12 | |
| *** TMM_ <[email protected]> has joined #litex | 07:12 | |
| tnt | _florent_: Yeah that'd be nice. I updated the platform/target files at https://people.osmocom.org/~tnt/stuff/adi/ | 07:18 |
| tpb | Title: Index of /~tnt/stuff/adi/ (at people.osmocom.org) | 07:18 |
| tnt | Also using this over litepcie (I rebased it on top of master) https://github.com/ylm/litepcie/commit/c707b300d6c4aab366b0bd583f437b355c486e27 | 07:19 |
| _florent_ | tnt: to test it, you loaded the bitstream and did a reboot of the machine or just a PCIe rescan? | 07:26 |
| tnt | _florent_: I reloaded the bitstream, typed 'reboot' (which I guess is warm reboot, it's remote so can't do off/on cycle) and then looked in lspci when it was back up. | 07:29 |
| tnt | However I'm not 100% sure there isn't something more fundamental wrong somewhere because I was never able to use the pcie clock as system clock ... | 07:29 |
| _florent_ | tnt: A reboot of the machine with the bitstream loaded is fine, so yes this could be related to the clock | 07:31 |
| _florent_ | tnt: is there an example design/bitstream with PCIe for this hardware? if so, this could be worth loading it and just see if you get something in lspci, just to verify the hardware | 07:39 |
| _florent_ | hardware/setup | 07:40 |
| tnt | _florent_: couldn't find one :/ The ADI bitstream doesn't have it AFAICT. | 07:42 |
| _florent_ | tnt: otherwise the LitePCIe integration seems fine | 07:52 |
| tnt | Can you probe anything from the bios prompt ? Link state / attempts / ... whatever ? | 07:57 |
| *** indy <[email protected]> has quit IRC (Remote host closed the connection) | 07:58 | |
| *** indy <[email protected]> has joined #litex | 07:59 | |
| _florent_ | there are some status registers: https://github.com/enjoy-digital/litepcie/blob/master/litepcie/phy/usppciephy.py#L27-L32 | 08:12 |
| _florent_ | but the support is not integrated in the BIOS, so you'll have to do manual mem_read | 08:13 |
| _florent_ | the reason is that on most of the PCIe designs I use, there are no CPU :) | 08:13 |
| tnt | Hehe, yeah. | 08:21 |
| tnt | I wonder if my issue could stem from the fact lanes 0-3 are on Quad 225 but the ref clock comes in on Quad 224 | 08:22 |
| _florent_ | It's possible to use a reference clock from another Quad, so if the design compiles fine it should be OK | 08:30 |
| tnt | yeah, but that's the thing ... the commit above sets the options to use Quad 224 which is where the clock is but not the data lanes. | 08:37 |
| _florent_ | tnt: can you check the final IO report to see if the Clock pins are still the one from the .xdc? | 08:41 |
| tnt | I'll rebuild and double check the io report. | 08:43 |
| *** ilia__s2 <[email protected]> has joined #litex | 09:10 | |
| *** ilia__s <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 09:14 | |
| *** ilia__s2 is now known as ilia__s | 09:14 | |
| tnt | Ok, so .. the clk signals was at the right place but the data was in quad 224 too which is wrong. I change the 224 to 225 in the .xci of litepcie and now io report shows clk in 224 and data in 225 which is good. | 09:30 |
| tnt | There was however some timing error in sys_clk ?!? (not sure why those appeared). | 09:31 |
| tnt | Tried the bitstream anyway and it did something ! ... not what I was hoping however : machine never rebooted. | 09:31 |
| _florent_ | arf... Doing PCIe bringup on a remote machine is not the easiest path... | 09:34 |
| leons | florent: still debugging my SFP issue. can you confirm there's no extra steps required compared to getting a DAC working? 🙂 | 10:23 |
| DerekKozel[m] | It's a big pain. Our student project has been 100% remote. I think we'd have proposed something a bit different if that had been obvious at the start. | 10:23 |
| leons | Okay that's good to know. Yeah, I've inverted the tx_disable polarity already accidentally haha | 10:23 |
| leons | My other device does see power, but no carrier | 10:23 |
| leons | Do you have any good idea on how to debug a missing/incorrect carrier? Maybe use an IBERT on another FPGA to see what's going on? | 10:23 |
| tnt | Plot twist: The machine isn't crashed ... the network just isn't working. And lspci shows Xilinx device 9034. | 10:40 |
| tnt | new pcie devices ... enp4s0 became enp5s0 ... | 10:48 |
| tnt | LnkSta:Speed 8GT/s (ok), Width x4 (ok) | 10:59 |
| mntmn | are the speedgrade_timings in litedram automatically selected? i mean, based on sth like (sys_clk_freq, "1:2") | 11:08 |
| mntmn | (or "1:4") | 11:08 |
| mntmn | hi _florent_ btw... i am quite comfortable with building my own bitfiles now | 11:09 |
| mntmn | also i get the feeling that the factor "1:2" vs "1:4" is ignored when instantiating a ddr module | 11:12 |
| _florent_ | tnt: Good :) | 11:14 |
| _florent_ | so now you could generate the drivers with: https://github.com/litex-hub/litex-boards/blob/master/litex_boards/targets/sqrl_acorn.py#L197-L198 | 11:15 |
| mntmn | yeah when i set the sys_freq to 200mhz and the memory module's rate to "1:2" i still get > 32-bit @ 1600MT/s (CL-11 CWL-8) | 11:15 |
| mntmn | but i would expect 800MT/s | 11:16 |
| _florent_ | tnt: and test it with: https://github.com/litex-hub/litex-boards/blob/master/litex_boards/targets/sqrl_acorn.py#L13-L24 | 11:16 |
| tnt | _florent_: yup, looking at the sw side now :) Tx for the pointers. | 11:16 |
| _florent_ | tnt: otherwise, if you are planning to use the DDR4 as I/Q sample buffers, I worked on DRAM based FIFOs last week that could be useful for this: | 11:21 |
| _florent_ | https://twitter.com/enjoy_digital/status/1446411651213844496 | 11:21 |
| _florent_ | This was not developed for SDR, but I'll problaby also use it on SDR designs in the future | 11:22 |
| _florent_ | leons: You could eventually use LiteICLink to debug your SFP issue | 11:24 |
| _florent_ | this will allow you to run PRBS tests between 2 FPGAs or between 2 SFP ports | 11:25 |
| tnt | _florent_: yeah, I saw that tweet and thought "Oh that's good timing, I might need that :D" | 11:25 |
| _florent_ | leons: ex : https://twitter.com/enjoy_digital/status/1332012363281821698 | 11:26 |
| _florent_ | leons: you would just need to adapt one of the LiteICLink test target: ex https://github.com/enjoy-digital/liteiclink/blob/master/bench/serdes/kcu105.py | 11:27 |
| _florent_ | leons: and then use test_prbs.py: https://github.com/enjoy-digital/liteiclink/blob/master/bench/serdes/test_prbs.py | 11:28 |
| _florent_ | mntmn: Hi, passing the speedgrade to the DRAM module is just useful to use the compute the internal timings, the speed shown in the BIOS is computed differently | 11:32 |
| mntmn | ahh ok | 11:32 |
| mntmn | _florent_: what's a recommended way to include my locally changed litex board/target when building linux-on-litex-vexriscv? PYTHONPATH? (i.e. i want to be able to make changes to the board definition/config on the fly) | 11:37 |
| _florent_ | mntmn: if litex-boards is installed in develop mode, you can directly modify the platform/target | 11:38 |
| *** andresmanelli <[email protected]> has quit IRC (Read error: Connection reset by peer) | 11:38 | |
| _florent_ | mntmn: otherwise, you can copy the files locally and modify the import in linux-on-litex-vexriscv's make.py | 11:39 |
| mntmn | _florent_: ok, thanks | 11:51 |
| tnt | _florent_: https://pastebin.com/8HNCA1vC | 12:05 |
| tpb | Title: root@ubuntu:/home/user/driver/user# ./litepcie_util infoFPGA identification: - Pastebin.com (at pastebin.com) | 12:05 |
| *** stfn <[email protected]> has joined #litex | 12:07 | |
| stfn | does anyone know if it's possible to write to the NVCM of iCE40 using open source tools? | 12:09 |
| tnt | It's not. | 12:10 |
| tnt | There has been some work and some stuff documented but there isn't an end-to-end tested flow for that. | 12:10 |
| stfn | would it be hard to reverse engineer? | 12:10 |
| tnt | I think it's pretty much "known" ... but you'll probably still destroy a few parts working out the details and implementing it ... | 12:11 |
| tnt | and ATM given stock ... I don't have a single part to waste | 12:11 |
| leons | _florent_: That looks indeed very interesting, thanks for the pointers! | 12:11 |
| stfn | I'll order 100 iCE40 they are dirt cheap | 12:12 |
| stfn | then just change them out on a dev board if it doesn't work out :) | 12:14 |
| tnt | _florent_: I seem to have an endianness issue ... | 12:33 |
| tnt | litepcie_readl(fd, CSR_IDENTIFIER_MEM_BASE + 4*i) >> 24 | 12:33 |
| tnt | I had to add the `>> 24' to get the correct value. | 12:33 |
| tnt | I'm assuming the dma_test has the same problem hence why it's not doing too well. | 12:34 |
| *** stfn <[email protected]> has quit IRC (Ping timeout: 265 seconds) | 12:37 | |
| _florent_ | tnt: strange, can you verify that csr_data_width is set to 32 and that the data-width of your PHY matches the one in your target? | 13:11 |
| tnt | _florent_: I added assert self.csr_data_width == 32 and it sent through, so csr_data_width seems OK. USPPCIEPHY is instanciated with data_width = 128 and litepcie/phy/xilinx_usp_gen3_x4/pcie_usp.xci MODELPARAM_VALUE.AXI4_DATA_WIDTH=128 if that's what you're asking. | 13:15 |
| _florent_ | tnt: ok, this seems fine, is there anything specific with the Host? | 13:17 |
| tnt | No, it's a box standard PC. https://www.gigabyte.com/Motherboard/B560M-AORUS-ELITE-rev-10/ mother board with a i7-11700 | 13:18 |
| tpb | Title: B560M AORUS ELITE (rev. 1.0) Key Features | Motherboard - GIGABYTE Global (at www.gigabyte.com) | 13:18 |
| tnt | board is plugged in the x16 slot normally used for GPU. | 13:18 |
| _florent_ | tnt: the issue is probably this: https://github.com/enjoy-digital/litepcie/blob/master/examples/xcu1525.py#L76 | 13:33 |
| *** lexano <lexano!~lexano@cpe00e06722f0e4-cm98524a70e35e.cpe.net.cable.rogers.com> has joined #litex | 13:33 | |
| _florent_ | tnt: the endianness does not seems to be configured correctly in LiteX-Boards for PCIe/Ultrascale | 13:34 |
| _florent_ | I'm going to fix that | 13:35 |
| tnt | yeah, atm I just do self.add_pcie(phy=self.pcie_phy, ndmas=1) | 13:35 |
| *** Guest48 <[email protected]> has joined #litex | 13:35 | |
| tnt | (since it's just a simple target for litex-board for now) | 13:35 |
| _florent_ | if you want to test while I'm doing that, you can force endianness to "little" here: https://github.com/enjoy-digital/litepcie/blob/master/examples/xcu1525.py#L76 | 13:35 |
| _florent_ | sorry wrong ling | 13:36 |
| _florent_ | link | 13:36 |
| _florent_ | here: https://github.com/enjoy-digital/litepcie/blob/master/litepcie/core/endpoint.py#L18 | 13:36 |
| tnt | Ok, trying that. | 13:37 |
| _florent_ | tnt: This should be fixed with https://github.com/enjoy-digital/litepcie/commit/b428fd533103f055fe5fa176ce54578311b38b1e and https://github.com/enjoy-digital/litex/commit/5e3e78f7604ede526a6946b6ff4e601018f4fb45 | 13:47 |
| tnt | _florent_: yeah, info returns the right string now and dma_test shows things :) ( https://pastebin.com/YKdwAP9j I assume the error on the first line is normal while bootstrapping ) | 13:52 |
| tpb | Title: $ ./litepcie_util dma_testDMA_SPEED(Gbps) TX_BUFFERS RX_BUFFERS DIFF ERRORS - Pastebin.com (at pastebin.com) | 13:52 |
| _florent_ | tnt: yes, this looks fine now, good | 13:53 |
| tnt | \o/ | 13:53 |
| tnt | I'll do a bit of cleanup but then I guess next step is going to be adding I2C / SPI cores so I can talk to the various chips on the board that need configuring. And then JESD. | 13:54 |
| tnt | Can the memory training be run from the host through PCIe btw ? | 13:54 |
| tnt | (I mean, I know it theorically can. Just not sure if it's supported / if there are examples) | 13:55 |
| _florent_ | if could be yes, but it's not supported currently | 14:00 |
| _florent_ | For your system, I would probably use LitePCIe and LiteDRAM as standalone cores (with 2 instances of LiteDRAM, each with its CPU) and re-integrate this in a LiteX SoC | 14:01 |
| _florent_ | This would use a bit more resources, but resources for the extra-CPUs, but resources almost come for free on these large devices | 14:02 |
| _florent_ | this would simplify the top level SoC | 14:03 |
| tnt | How so ? | 14:06 |
| tnt | I mean really I only need the CPU for the calibratio n... here it's nice for peek/poke through uart and see how stuff is running, but in the end, I don't even need the cpu to have access to the RAM (have it memory mapped). | 14:07 |
| _florent_ | With LiteDRAM/LitePCIe, you can generate standalone core with litedram/litepcie_gen and .yml configuration files | 14:11 |
| _florent_ | ex for LiteDRAM: https://github.com/enjoy-digital/litedram/blob/master/examples/xcu1525.yml | 14:12 |
| _florent_ | ex for LitePCIe: https://github.com/enjoy-digital/litepcie/blob/master/examples/kcu105.yml | 14:13 |
| tnt | Ah by "how so" I meant more "why do you think it's necessary / would help". | 14:13 |
| _florent_ | With LiteDRAM, you can also disable the CPU and expose a Wishbone interface instead to do the calibration: https://github.com/enjoy-digital/litedram/blob/master/examples/xcu1525.yml#L10 | 14:14 |
| _florent_ | setting cpu to None | 14:14 |
| _florent_ | that's what is used by the Microwatt team for example to avoid the extra CPU | 14:15 |
| _florent_ | When the design becomes complex, using the standalone cores can help since increase decoupling (the main SoC is "just" integrating a PCIe core, 2 DRAM cores, a JESD cores with clear interfaces + extra peripherals/modules) | 14:17 |
| _florent_ | but each developer will probably have different preferences on this | 14:19 |
| _florent_ | For the extra-cpus, that's what is done heavily in Intel/Xilinx design embedding lots of soft cores CPU in IPs | 14:20 |
| tnt | Yeah, I think I'll have to see for myself when I start hitting something to have a better understanding. | 14:20 |
| tnt | Right, I saw MIG is embedding a while microblaze ... | 14:20 |
| tnt | -while+whole | 14:20 |
| _florent_ | I'm not saying we should do the same :) but with LiteX we can choose which CPU is the best for each usage, so for LiteDRAM, you could use a small CPU: serv or VexRiscv Minimal | 14:20 |
| tnt | yup, SERV is what I was thinking :) | 14:21 |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 14:43 | |
| *** TMM_ <[email protected]> has joined #litex | 14:43 | |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Ping timeout: 245 seconds) | 15:28 | |
| Guest7846 | Hi All, I have been seeing this error since the latest pull from Litex: "ERROR:SoCBusHandler:Region overlap between ethmac and csr:" | 16:12 |
| Guest7846 | Any idea what could be happening there? | 16:12 |
| Guest7846 | I have looked around soc.py, but nothing seems obvious | 16:13 |
| Guest7846 | INFO:SoCBusHandler:main_ram Region added at Origin: 0x40000000, Size: 0x40000000, Mode: RW, Cached: True Linker: False. | 16:14 |
| Guest7846 | INFO:SoCBusHandler:main_ram added as Bus Slave. | 16:14 |
| Guest7846 | INFO:SoCBusHandler:Allocating IO Region of size 0x00002000... | 16:14 |
| Guest7846 | INFO:SoCBusHandler:ethmac Region allocated at Origin: 0x00000000, Size: 0x00002000, Mode: RW, Cached: False Linker: False. | 16:14 |
| Guest7846 | INFO:SoCBusHandler:ethmac added as Bus Slave. | 16:14 |
| Guest7846 | Looks like ethmac of kc705 is getting added at 0x000000.. for some reason | 16:15 |
| _florent_ | Guest7846: This should be fixed with https://github.com/enjoy-digital/litex/commit/a489dadfbc2a63cd6db48db6d0112f4a1845dff3 | 16:31 |
| _florent_ | Guest7846: If not, can you provide the command? | 16:31 |
| leons | florent: after many days of trying to get the optical SFP+ path working, the cause is finally identified: the SFP+ module was broken. | 16:45 |
| leons | I would’ve never expected the literally only non-custom designed/programmed part of my project to be the culprit | 16:46 |
| mntmn | _florent_: got linux running. | 16:47 |
| _florent_ | leons: That's good you got it working, you probably learn new things during the process so the time was probably not completely lost... (at least that the way I try to see things when such things happen to me :)) | 16:53 |
| _florent_ | mntmn: That's great! If you want a faster boot, you should be able to netboot (with the images on the tftp server at 192.168.1.100 by default) or boot from the SDCard | 16:54 |
| leons | That’s certainly true. For one I learned that my devboard is a horrible piece of hardware and I did get to read through some specs in the process :) | 16:54 |
| mntmn | _florent_: ah good hint! i will set up netboot | 16:54 |
| mntmn | funny that my computer with tftp has this ip already... | 16:54 |
| _florent_ | mntmn: For the SDCard boot, I think last time we tried together the SDCard was probably not formated correctly | 16:55 |
| _florent_ | or maybe you could try with another | 16:55 |
| mntmn | _florent_: ok i will try to add some debug statements to the sdcard loader | 16:55 |
| mntmn | _florent_: the sdcard works in linux | 16:55 |
| mntmn | (on the same device) | 16:55 |
| _florent_ | the process is the same: copy the images to the SDCard and it should boot | 16:55 |
| *** kgugala <[email protected]> has joined #litex | 16:58 | |
| mithro | _florent_ / kgugala: There was a student from Princeton that was porting https://parallel.princeton.edu/papers/micro19-gao.pdf to work with LiteDRAM -- any idea what happened with that? | 16:59 |
| kgugala | haven't heard from him for a while | 17:00 |
| _florent_ | mithro: I also don't know, but IIRC Finde here could maybe have more info | 17:01 |
| Finde | it was Fei himself who was porting it | 17:06 |
| Finde | you can contact him directly to ask | 17:06 |
| Finde | afaik he had something working but I don't remember the details | 17:06 |
| *** lexano <lexano!~lexano@cpe00e06722f0e4-cm98524a70e35e.cpe.net.cable.rogers.com> has quit IRC (Remote host closed the connection) | 17:10 | |
| *** lexano <lexano!~lexano@cpe00e06722f0e4-cm98524a70e35e.cpe.net.cable.rogers.com> has joined #litex | 17:21 | |
| tnt | How was pcie_support.v generated btw ? I can't see it in the output products of vivado when creating the IP. | 18:42 |
| _florent_ | tnt: it's one of the top level file with some custom logic to translate the "new" protocol used by Xilinx on AXI-stream to standardized TLPs (that LitePCIe was already supporting) | 20:27 |
| _florent_ | tnt: the main differences between 7-Series PCIe PHY and Ultrascale are: | 20:27 |
| _florent_ | - different protocols on the AXI streams. | 20:28 |
| _florent_ | - Separate streams for requests/completions on Ultrascale. | 20:29 |
| *** lexano <lexano!~lexano@cpe00e06722f0e4-cm98524a70e35e.cpe.net.cable.rogers.com> has quit IRC (Remote host closed the connection) | 20:45 | |
| *** lexano <lexano!~lexano@cpe00e06722f0e4-cm98524a70e35e.cpe.net.cable.rogers.com> has joined #litex | 21:25 | |
| *** zjason` <zjason`[email protected]> has joined #litex | 21:49 | |
| *** Guest48 <[email protected]> has quit IRC (Ping timeout: 256 seconds) | 21:49 | |
| *** zjason <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 21:51 | |
| *** andresmanelli <andresmanelli!~andresman@2a01:cb19:8c36:4900:3822:311c:ffc8:8d2> has joined #litex | 22:19 | |
| *** andresmanelli <andresmanelli!~andresman@2a01:cb19:8c36:4900:3822:311c:ffc8:8d2> has quit IRC () | 22:26 | |
| *** Guest4888 <[email protected]> has joined #litex | 23:40 | |
| *** mc6808 <[email protected]> has joined #litex | 23:43 | |
| mc6808 | I'm having issues with litescope recently: I can do an immediate capture but if I try to use a trigger litescope_cli dies on an empty ethernet packet litex/litex/tools/remote/etherbone.py", line 306, in decode | 23:47 |
| mc6808 | header = list(ba[:etherbone_packet_header.length]) | 23:47 |
| mc6808 | TypeError: 'int' object is not subscriptable | 23:47 |
| mc6808 | Anyone else have an experience like this? A few months ago litescope was extremely reliable for me but this started happening occasionally and now triggering is unusable. | 23:48 |
| mc6808 | FYI Not sure if this is just me for some reason? I'm using a ecpix5 board and there are some litescope timing warnings. | 23:49 |
| mc6808 | Warning: Max frequency for clock '$glbnet$eth_clocks_rx$TRELLIS_IO_IN': 106.77 MHz (FAIL at 125.00 MHz) | 23:50 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!