<tpb>
Title: Ive seen pcie literally run over a metal clothes hanger soldered to the board. ... | Hacker News (at news.ycombinator.com)
lambda has joined #litex
<xobs>
True, but I think most of the bugs and lockups I encountered were during enumeration.
<xobs>
Basically, how fidlly is it? Do you need to restart the host every time you redo the firmawre on the device?
<mithro>
xobs: No idea, I haven't actually tested it :-P
<xobs>
I see.
<mithro>
kgugala: Might know
<xobs>
Still, if I had access to a machine with one of those in there running a gateware with a wishbone bridge, I don't think it would be too difficult to add support for it in `wishbone-tool`.
<mithro>
I know they were struggling with the buffer allocation and DMA pointer updates
<mithro>
(Getting tearing and something around color?)
<xobs>
The problem is I only have a few machines with PCIe slots, and they don't really like being turned off or rebooted.
<mithro>
xobs: I have a bunch of turbots sitting here waiting for me to set them up for exactly that
<xobs>
(I have enough troubles with this DVB-T2 USB card causing KPs whenever it's disconnected.)
<john_k[m]>
I just put up a litex PR to add a concept of an SDK for the generated SoC, that is a standalone set of headers, makefile fragments, and binaries to enable building firmware for the generated SoC without relying on litex internals. This came from a conversation with Mubes on 1BitSquared Discord. (https://github.com/enjoy-digital/litex/pull/487)
<john_k[m]>
Would love feedback / pointers on how to do this better
<_florent_>
xobs: PCIe is quite reliable and not that complicated, the only thing that is not very convenient during dev is that you have to reboot the machine when reloading the bitstream for the enumeration, but on Linux it seems possible to do a PCIe rescan (but haven't spend the time to get it work) and when passing through thunderbolt (card in an expansion chassis) it automatically re-enumerate.
<_florent_>
xobs: i could give you remote access to a NeTV2 board connected to a Host through PCIe if you want to do some wishbone-tool tests
<xobs>
_florent_: that's the code I was going off of! Is all of Wishbone mapped there? Is it a 4gb file?
<_florent_>
john_k[m]: thanks john_k[m], i will look at that. I think @esden, @xobs, @bunnie could also be interested by that since are replacing the BIOS with custom firmware and use LiteX to generate just the gateware/headers.
<john_k[m]>
Cool, thanks _florent_
<_florent_>
xobs: on most of the systems, i'm only exposing the CSR region, so with a reduced BAR0 size and CSR region mapped to address 0. But we could use a larger BAR0, the larger i tested was 512MB, but it could probably be increased.
<xobs>
I see. Is that offset exposed anywhere in the csr.csv file anywhere?
<xobs>
Or maybe we could make it a banked window.
<xobs>
For example, there's a Wishbone command to jam a file into ram.
CarlFK has quit [Ping timeout: 260 seconds]
CarlFK has joined #litex
HoloIRCUser has joined #litex
HoloIRCUser2 has quit [Ping timeout: 264 seconds]
<_florent_>
xobs: we can retrieve this information from the .csv file yes.
<_florent_>
daveshah: from your write leveling results, it seems there is a large delay difference on the clk/cmd between modules 0-3 and modules 4-8, not sure this a situation i already encountered, maybe we should handle it by allowing dynamic cmd latency and allow the software to test different cmd_latency for each byte. I could investigate that when i'll reveice a similar board.
<daveshah>
Makes sense
<_florent_>
daveshah: in case you think you are not going to modify your changes, could you create a PR for the different changes? This will allow starting integrating them and going further.
<daveshah>
They need tidying up first, but I will do
<daveshah>
(in particular making the RDIMM stuff conditional on an RDIMM being used)
<_florent_>
daveshah: ok perfect, thanks.
<_florent_>
while the issue is not fixed, if you need the DRAM you could probably restrict LiteDRAM to only use half of the modules, i could add a function to ease that as we discussed.
HoloIRCUser1 has joined #litex
HoloIRCUser has quit [Ping timeout: 260 seconds]
<daveshah>
I might also experiment trying different channels, if the difference is due to routing on the board rather than the DIMM
<tpb>
Title: common: add PHYPadsReducer to only use specific DRAM modules. · enjoy-digital/litedram@9a2d3f0 · GitHub (at github.com)
<daveshah>
Thanks! I can also re-enable all 72 bits now too
<daveshah>
This won't work for the U250 as is though, because it is using x4 DQS
<_florent_>
daveshah: yes i was thinking about that
<_florent_>
daveshah: we could add more parameters to support it
<daveshah>
On the phy side for now I added a x4_dimm_mode that disables DM and duplicates DQS (currently using the same delay for both nibbles in a byte which seems to work here, but might need to be changed to per nibble control for other boards)
<_florent_>
ok, in fact we could also probably avoid the parameter (for the PHY and PHYPadsReducer too) by looking at the len(pads.dq)/len(pads.dqs) ratio
<daveshah>
Oh yeah, that makes sense
<daveshah>
I guess we could just disable DM if the pads aren't present, too
<_florent_>
you we could do that for DM, that's what we are doing in GENSDRPHY IIRC
<daveshah>
_florent_: how should "this is an RDIMM" and the RDIMM configuration (which needs to include the clock frequency) be passed to get_sdram_phy_init_sequence ?
<_florent_>
we should probably add that to the phy_settings
<scanakci>
how can I undefine a MACRO used in multiple files in soc/software? CONFIG_CPU_HAS_INTERRUPT is defined by default and I need to undef it (potentially modifying genesys.py)
<_florent_>
scanakci: you want to avoid interrupts with blackparrot right?
<scanakci>
yeah, I am using polling not external interrupts
<_florent_>
so if you are not using the interrupts, you can remove the interrupt signal of the CPU wrapper, it will automatically switch to UART_POLLING
<daveshah>
_florent_: I've created a PR for the x4 support and adding the module, I'll need to spend a bit longer on the RDIMM init
<_florent_>
daveshah: ok thanks, i'll look at these PRs.
m4ssi has joined #litex
<zyp>
hmm, I assume the litex bios uses the rom and sram regions, so that if I want to serialboot my own code, I either need to load it into main_ram or add a second sram area for it?
<tpb>
Title: GitHub - enjoy-digital/litedram_init_test: Example of LiteDRAM initialization with a firmware in RAM loaded via serialboot. (at github.com)
rohitksingh has quit [Remote host closed the connection]
<zyp>
how does interrupts work? I'm used to there being a vector table at the beginning of the image
<xobs>
_florent_: if you want to set up a server so I can add pcie support, I can try that tomorrow.
<zyp>
_florent_, thanks, I'll have a look
<_florent_>
xobs: ok great, i'll prepare that this afternoon
scanakci has quit [Quit: Connection closed for inactivity]
gregdavill has quit [Ping timeout: 240 seconds]
CarlFK has quit [Quit: Leaving.]
CarlFK has joined #litex
CarlFK has quit [Ping timeout: 258 seconds]
HoloIRCUser has joined #litex
HoloIRCUser1 has quit [Ping timeout: 256 seconds]
scanakci has joined #litex
<john_k[m]>
mithro: re SDK PR, shipping the output directory isn’t sufficient as many headers and a makefile fragment live in the Litex source tree. The goal here is to have a release artifact (eventually including docs) that can be distributed alongside gateware so end users can develop firmware for the SoC without needing to care about Litex/FPGA toolchains/python modules
<shuffle2>
i have some existing verilog code that generates a stream of data, and i'm trying to send it out via LiteEthUDPIPCore. the stream is variable length data
<shuffle2>
so i've wrapped it in stream.Endpoint, assigned .valid and .last, and UDP sends the appropriate data content + length
<shuffle2>
however the udp size field is not set correctly
Skip has joined #litex
<shuffle2>
should I be using Packetizer? i need to decode the beginning of the stream to figure out packet length. doing this myself and then assigning .length of the eth_udp_user_description still results in 0 data size in udp header. so i assume LiteEthUDPTX requires length to be set at packet start and i'm missing the window?
<shuffle2>
buy just from looking at the python i dont really get where the issue is :/
<shuffle2>
but*
<mithro>
john_k[m]: Do you mean the libcompiler_rt stuff?
<mithro>
john_k[m]: We should really be pushing people developing their own firmware to be using newlib or similar?
<john_k[m]>
all of the headers from `litex/soc/software/include/` and `common.mak`
<zyp>
I'm about to start adding riscv support to my arm mcu hardware abstraction lib, I'm planning to just ingest the csr.csv/json and generate my own headers from that
<john_k[m]>
maybe for some larger projects, sure
<mithro>
john_k[m]: I would say pretty much everything under the `include` directory should potentially go away
<john_k[m]>
hrm, interesting
<mithro>
john_k[m]: I do think you are potentially going in the right direction in that everything under the build directory should be what is needed to use the fpga
<john_k[m]>
I guess that all makes sense, I think the goal here was just to reduce barriers to getting things started.
<mithro>
john_k[m]: Yeap! Maybe it makes sense to land something like this temporarily with a goal of deleting it in the future?
<john_k[m]>
I had to look at a few different examples: esden's icebreaker-examples and litex-hub's fpga-101 to figure out how to get started with my first firmware project - would be great if litex made that easier
<john_k[m]>
maybe? could be an ecosystem bootstrapping thing?
<mithro>
john_k[m]: So, I'm not suggesting that we /can't/ merge this pull request - just trying to give you some more context or other potential ideas
<john_k[m]>
yep, I didn't take it that way - like I said, just wanted to spark some conversation here and try to figure out how to make getting started easier and for people writing FW
<john_k[m]>
would be open to helping on the libc front as well
<mithro>
john_k[m]: It's been on our todo list for a long time -- the primary thing blocking it is the LTO support
<john_k[m]>
LTO support in what part?
<john_k[m]>
does gcc not support it yet? It looks like LTO for clang / riscv was added in v10.0
<mithro>
Link time optimization
<john_k[m]>
yep, that's what I assumed you were referring to - what's the roadblock?
<tpb>
Title: software: enable link time optimization (LTO) by mateusz-holenko · Pull Request #401 · enjoy-digital/litex · GitHub (at github.com)
<mithro>
john_k[m]: But it was revert
<mithro>
mateusz-holenko knows the current status (and works for kgugala)
<john_k[m]>
aha, thanks I'll read up on it
<shuffle2>
i guess i need to setup this litescope thing over uart to try and figure out what's wrong? :(
m4ssi has quit [Remote host closed the connection]
<shuffle2>
is there some actual expectation about how you should (or should not) drive and Endpoint's first/valid/last/etc?
<shuffle2>
an*
<shuffle2>
i created a udp crossbar with datawidth=16 and udp logic is somewhere byteswapping the data :|
<shuffle2>
crossbar port*
CarlFK has joined #litex
<dkozel>
Ha, hi xobs I'll test out your Rust code in the next two days.
<dkozel>
ah, and I see florent is going to setup a server. If for whatever reason that doesn't work out I can DM you access to a live environment here with a PCIe card