| *** tpb <[email protected]> has joined #litex | 00:00 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 244 seconds) | 00:04 | |
| *** Degi_ <[email protected]> has joined #litex | 00:04 | |
| *** Degi_ is now known as Degi | 00:04 | |
| *** nickoe <[email protected]> has quit IRC (Quit: Client closed) | 01:37 | |
| *** nickoe <[email protected]> has joined #litex | 01:38 | |
| *** Degi_ <[email protected]> has joined #litex | 04:01 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 250 seconds) | 04:03 | |
| *** Degi_ is now known as Degi | 04:03 | |
| *** slagernate <[email protected]> has quit IRC (Quit: Client closed) | 04:05 | |
| *** nickoe <[email protected]> has quit IRC (Quit: Client closed) | 04:25 | |
| *** nickoe <[email protected]> has joined #litex | 04:26 | |
| *** cr1901 <cr1901!~cr1901@2601:8d:8600:911:5485:20e1:cdc4:b4f2> has quit IRC (Read error: Connection reset by peer) | 04:48 | |
| *** FabM <FabM!~FabM@2a03:d604:103:600:2e60:8c7c:e8fb:7990> has joined #litex | 06:04 | |
| *** cr1901 <cr1901!~cr1901@2601:8d:8600:911:560:ea8a:1221:40d4> has joined #litex | 06:49 | |
| *** Brinx <[email protected]> has quit IRC (Remote host closed the connection) | 08:16 | |
| *** Brinx <[email protected]> has joined #litex | 08:45 | |
| *** Brinx <[email protected]> has quit IRC (Remote host closed the connection) | 08:48 | |
| *** Brinx <[email protected]> has joined #litex | 08:49 | |
| *** Brinx <[email protected]> has quit IRC (Ping timeout: 264 seconds) | 08:54 | |
| tnt | A bit more details tracing my PCIe issue : In the "bad" case, I sometime get almost 5 ms (so basically forever at this timescale) between two consecutive litepcie_writel() | 09:01 |
|---|---|---|
| tnt | In the "good" case, I observe an absolute max of 5 us between two consecutive access (so 1000x less !) | 09:02 |
| *** nickoe <[email protected]> has quit IRC (Quit: Client closed) | 09:08 | |
| *** nickoe <[email protected]> has joined #litex | 09:09 | |
| *** Brinx <[email protected]> has joined #litex | 09:21 | |
| tnt | There seem to be one such insanely slow access every 120 ms | 09:33 |
| *** Brinx <[email protected]> has quit IRC (Remote host closed the connection) | 09:37 | |
| *** Brinx <[email protected]> has joined #litex | 09:38 | |
| *** Brinx <[email protected]> has quit IRC (Ping timeout: 246 seconds) | 09:46 | |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 10:05 | |
| *** TMM_ <[email protected]> has joined #litex | 10:05 | |
| *** Brinx <[email protected]> has joined #litex | 10:35 | |
| *** Brinx <[email protected]> has quit IRC (Remote host closed the connection) | 10:37 | |
| minute | hmm, looks like spiflash_read_status_register() is unreliable somehow | 11:21 |
| minute | i have some code that erases flash sectors and polls spiflash_read_status_register(), and i can see that the erases are not complete, only the first ~half of the 4096 byte regions are erased | 11:22 |
| minute | if i do the erase manually one 4096b sector at a time, it works | 11:22 |
| *** nickoe <[email protected]> has quit IRC (Quit: Client closed) | 11:30 | |
| *** nickoe <[email protected]> has joined #litex | 11:30 | |
| zyp | have you checked that the erase size is correct for your flash? | 11:53 |
| minute | zyp: yep, it's 25Q128JV | 11:56 |
| minute | W25Q128JVS | 11:56 |
| minute | zyp: i've now switched to 64kb erase command, and it's going much too quick... i.e. there's something wrong with reading the busy flag | 11:57 |
| minute | so i'm gonna printf debug the read status register 1 responses | 11:58 |
| minute | i'm using code that's almost identical to https://github.com/butterstick-fpga/dfu-runtime-soc/blob/3407f80497151498a7dc21c1e58cf73668e0d02f/firmware/flash.c | 11:59 |
| minute | ok so the existing code returns the second byte of the read status response, but the status is actually in the first byte | 12:20 |
| *** nickoe17 <[email protected]> has joined #litex | 12:29 | |
| zyp | the first byte is whatever is shifted in while the command byte itself is shifted out | 12:31 |
| zyp | unless your approach is different from the others | 12:31 |
| *** nickoe <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 12:33 | |
| minute | zyp: then there's something weird going on with the timing perhaps | 12:40 |
| minute | i'm getting 0x43/0x40, 0xff in the transfer buffer after an erase command | 12:41 |
| minute | but also, they transfer the erase command followed by a zero byte for some reason | 12:42 |
| minute | sorry, not true | 12:42 |
| minute | they transfer the read status register command followed by a zero byte | 12:42 |
| minute | ok that makes sense | 12:42 |
| zyp | yes, spi is bidir, you shift two bytes in total, first byte is command out and dummy in, second byte is dummy out and status in | 12:54 |
| minute | thanks for explaining... so it appears that sometimes things can get out of phase? | 12:56 |
| zyp | it really shouldn't | 12:57 |
| *** Brinx <[email protected]> has joined #litex | 12:57 | |
| *** Brinx <[email protected]> has quit IRC (Remote host closed the connection) | 12:58 | |
| *** Brinx <[email protected]> has joined #litex | 12:58 | |
| tnt | Is litescope "trigger_depth" the "pre-trigger" ? | 13:26 |
| tnt | (i.e ideally I'd like to have the trigger centered, with N samples before trigger and N samples after the trigger) | 13:27 |
| minute | ok, i've got this kintex-7 to load litex bitstream from spi flash. it's very slow though, seems like ConfigRate is at 3mpbs? | 14:23 |
| minute | how can i set the bitstream ConfigRate for series 7/vivado? bitgen_opt doesn't exist | 14:24 |
| minute | i guess this has to go into the constraints | 14:24 |
| *** Guest1392 <[email protected]> has joined #litex | 14:26 | |
| minute | aha mhm https://github.com/timvideos/litex-buildenv/issues/79 | 14:27 |
| *** Brinx <[email protected]> has quit IRC (Remote host closed the connection) | 14:45 | |
| *** Brinx <[email protected]> has joined #litex | 14:46 | |
| *** Brinx <[email protected]> has quit IRC (Ping timeout: 244 seconds) | 14:50 | |
| *** Guest1392 <[email protected]> has quit IRC (Quit: Client closed) | 15:35 | |
| *** Brinx <[email protected]> has joined #litex | 15:44 | |
| *** Brinx <[email protected]> has quit IRC (Ping timeout: 265 seconds) | 15:48 | |
| minute | was there already any work done on getting DMA memory copying in linux? i.e. for scrolling in the framebuffer | 15:49 |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Ping timeout: 268 seconds) | 16:21 | |
| *** Brinx <[email protected]> has joined #litex | 16:40 | |
| *** SpaceCoaster <SpaceCoaster!~derek@user/spacecoaster> has quit IRC (Ping timeout: 265 seconds) | 16:46 | |
| *** SpaceCoaster <SpaceCoaster!~derek@user/spacecoaster> has joined #litex | 17:07 | |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 17:30 | |
| *** TMM_ <[email protected]> has joined #litex | 17:30 | |
| minute | at 150mhz and 4 cores i'm getting random crashes during linux boot, now checking if that's due to smp or 150 vs 100 mhz | 17:49 |
| minute | back to 100mhz but still at 4 cores, it gets to init but then > [ 17.008844] ln[69]: unhandled signal 11 code 0x1 at 0x2b66a0d4 in ld-linux-riscv32-ilp32.so.1[95b64000+21000] | 17:55 |
| *** slagernate <[email protected]> has joined #litex | 18:15 | |
| slagernate | anyone want to help me get a simple litex demo working? https://github.com/enjoy-digital/litex/issues/1441 | 18:16 |
| slagernate | ;) | 18:16 |
| *** slagernate <[email protected]> has quit IRC (Quit: Client closed) | 18:20 | |
| *** FabM <FabM!~FabM@2a03:d604:103:600:2e60:8c7c:e8fb:7990> has joined #litex | 18:24 | |
| *** slagernate <[email protected]> has joined #litex | 18:46 | |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Ping timeout: 246 seconds) | 18:56 | |
| minute | yeah sigh smp appears broken somehow... linux works fine with only 1 cpu in the dtb, but if the 4 cores are active, init crashes | 19:02 |
| minute | > [ 16.680009] init[1]: unhandled signal 11 code 0x1 at 0x00000000 in busybox[69355000+df000] | 19:09 |
| minute | strangely, dual core works | 19:29 |
| tnt | slagernate: huh ... how is that supposed to boot ? | 19:34 |
| tnt | LRAM can't be initialized IIRC. And there is no flash ... so what do you expect the CPU to execute ? | 19:35 |
| minute | not stable though @ 2 cores, udhcpc kills everything | 19:35 |
| tnt | Or does it create ROM automatically ? | 19:36 |
| slagernate | Where does it say LRAM can't be initialized? The memory usage guide for the nexus platform (https://www.latticesemi.com/view_document?document_id=52785) on page 77 says "In each memory mode, it is possible to specify the power-on state of each bit in the memory array. This allows the memory to be used as ROM if desired." | 19:57 |
| slagernate | I mean, my assumption was that the target/lattice_crosslink_nx_evn.py file was already working and didn't have any egregious flaws | 19:59 |
| slagernate | There are lattice_crosslink_nx_evn_[mem/rom].init files in the gateware directory --my assumption was that these were packed into the .bit file, but I could be terribly wrong (maybe gatecat can comment) | 20:00 |
| tnt | Ok, my bad, I thought the LRAM had the same limitation than the SPRAM in the UP5k. | 20:04 |
| tnt | But you're probably the second person, maybe third to try the crosslink nx most likely ... | 20:04 |
| slagernate | All good. Yeah, true, I guess [porting litex to the crosslink NX](https://github.com/enjoy-digital/litex/issues/618) should be reopened. CC tcal alanvgreen _florent_ See: https://github.com/enjoy-digital/litex/issues/1441. Going to try an external UART and get back to you tho | 20:12 |
| *** slagernate <[email protected]> has quit IRC (Quit: Client closed) | 20:32 | |
| *** Brinx <[email protected]> has quit IRC (Remote host closed the connection) | 20:47 | |
| *** Brinx <[email protected]> has joined #litex | 20:47 | |
| *** Brinx <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 20:52 | |
| *** slagernate <[email protected]> has joined #litex | 21:06 | |
| minute | did something change in liteeth that breaks the linux driver? | 21:07 |
| minute | system basically freezes now when interacting with eth0 and it used to work fine | 21:08 |
| tcal | Yes, I do recall bringing up LiteX on an EVN board a couple of years ago, using an external UART. I was quite new at these things at the time. I remember it being somewhat confusing writing to flash, then resetting it using a button? Or power cycling it? Or possibly with another ecpprog option, writing the bitstream to RAM config storage. It's pretty blurry... | 21:10 |
| tcal | slagernate: ^^ | 21:11 |
| minute | when interacting with liteeth from linux, i get after a while a > [ 288.331419] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: | 21:12 |
| slagernate | tcal I see. The native crosslinknx eval board uart isn't working, so I will try an external UART | 21:37 |
| slagernate | To be clear, I can program the fpga well (the LED chaser output is working) | 21:38 |
| tcal | Oh, I realized that my prior experience wasn't using the litex-boards target file, but an older version of building a LiteX SoC (anyone remember lxbuildenv.py?). We did use the litex-boards platform file for the EVN board though. | 21:48 |
| tcal | Wait, another thing occurred to me...there is a Yosys issue that causes our current design on the LIFCL-17 to not work. https://github.com/YosysHQ/yosys/issues/3416 | 21:53 |
| slagernate | I'm actually using lattice radiant (LSE synthesis tool, not synplify pro) | 21:56 |
| slagernate | but I suspect my setup will work once a try a different (external) UART | 21:57 |
| slagernate | how has working with LIFCL-17 (CrosslinkNX FPGA) been for you tcal? Am planning to use it extensively | 22:06 |
| tcal | Ah yes, I'd forgotten about the choices you have with Nexus. LiteX even supports a Yosys (synth) --> Radiant (P&R) flow. We haven't used Radiant synthesis for quite a while since there was an issue where it wouldn't let us use all of the EBRs. As for the LIFCL-17 itself, it's a good fit for our use case -- a pretty good balance of RAM, DSP blocks, and logic cells. | 22:13 |
| *** nickoe17 <[email protected]> has quit IRC (Quit: Client closed) | 22:28 | |
| *** nickoe17 <[email protected]> has joined #litex | 22:28 | |
| slagernate | Glad to hear it's working acceptably well | 23:06 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!